Jason L. Froebe: Ramblings of a Geek

git for Perl projects?

by andreas1234567

I recently listened to Randal Schwartz‘ (aka merlyn) and Leo Laporte’s podcast interview with Junio Hamano, maintainer of the git version control system, on FLOSS weekly episode 19. Mr. Schwartz revealed that he is using git for his source code management, either directly (”anything I get to choose, I use git”), or as a front-end to CVS or Subversion through git’s interface layers (”they don’t know I’m using git”).

I was intrigued by some of the features of git, for instance the ability to track the child-parent relationship for every commit using cryptographic hashes.

I’ve been using CVS up until now, but the way it prevents moving and renaming files makes me want to consider alternatives. Until I heard the above podcast that alternative has been Subversion only.

The Perl projects I work on are neither very large nor distributed. Should I consider git as my future SCM for Perl projects? What are the Monks’ experience with using git in Perl projects?

–
Andreas

Andreas brings up an interesting question:  What should we use for Perl development.  I replied to Andreas with:

Re: git for Perl projects?
by jfroebe on Sep 28, 2007 at 21:24 GMT-6

For the most part, it really doesn’t matter which version control system you use. Think about it.. for most open source or even commercial projects, you have a small number of developers that are active on the project. Usually in the single digits. The level of sophistication required of the version control system isn’t pretty high - checkout/checkin/comment/etc. It isn’t until you have a lot more developers, a very complex project, or some other thing. Using CVS, Subversion, GIT, rcs, or even SCCS will work fine for most projects.

GIT is just the revision control system flavor of the week for primarily the Linux kernel developers. If you want to use it, do so. If not, don’t worry about it. Use what feels comfortable to you.

hope this helps,

Jason L. Froebe

Listen to this podcast

We use subversion a great deal but I don’t understand why there are people that refuse to use it.  The TechRepublic article, Avoid these six common development mistakes, sheds a bit of light:

….

4. Failing to see the value in a version control system

Most developers are all-too-familiar with this scenario: You roll out a new version of a critical Web application, and your cell phone rings constantly the next morning with cries of site problems.

As long as you’re willing to admit that you may have made a mistake or two, a version control system can be your best friend in this situation. By using version control systems, such as CVS, IBM Rational ClearCase, or Microsoft Visual SourceSafe, you can easily revert to the previous version of the application and move it to production. This gives you time to locate the problems within the development environment while the production site is readily available. This beats frantically searching through production code to locate the problem.

In addition, a source control system allows concurrent development so different team members may work with the same code. When the developers check their changes into the system, the changes are merged together.

One reason why some developers don’t like version control systems is because it adds a layer to the development process, which means the submission and retrieval of code to and from the source control system can be slow. This extra waiting time can tax the patience of some developers.
Read more…

Hmmm.  It might be more of a matter of convenience for some developers not to use or learn how to use a revision control system.  Looks like I’ll have to write a few wrappers to simplify it.

Listen to this podcast

Remember my Sybase Replication Server: custom built RepAgents with Perl! post back last year? Well, not only am I the new maintainer, but I finally have it working in a test environment. It isn’t ready for a new release for Sybase::TdsServer and Sybase::RepAgent, yet, but expect one soon.

My main development environment for these two modules is:

• Windows XP SP2
• ActiveState Perl 5.8.8
• Sybase Workspace 1.7 (Eclipse based)
1. EPIC Perl plugin
2. Subclipse (subversion client)

I’m hoping to get out my first CPAN release to the perl testers within the next month or so. Why the delay? My wife and I are expecting family and friends to stay with us for the next few weeks. That’s a very good thing

Listen to this podcast

If you try to add the subversion plugin Subclipse to Sybase’s Workspace version 1.6 or 1.7, you will receive the following error:

To work around this problem, you need to start Eclipse.exe directly, usually located in your %SYBASE%\Workspace\Eclipse directory. Go to Help -> Software Updates -> Find and Install -> Search for new features. Add the url (http://subclipse.tigris.org/update_1.0.x) and Name (subclipse). When you’re given the option to install, uncheck the “Show the latest version of a feature only”.

We need to use version 1.0.5 of subclipse because Sybase’s Workspace is running on top of the older Eclipse version 3.1 software. The newer subclipse requires Eclipse 3.2 or higher to work.

Uncheck “Subclipse 1.2.0″ and check “Subclipse 1.0.5″.

Continue installing, ignore any warnings.

The other option, of course, is to install Eclipse 3.2x separately and point Workspace to it during the install of Workspace. That way we are able to use the current version of Eclipse. I have not tried this with the new Workspace 1.7 release yet. Sybase Workspace is hardcoded to work only with Eclipse 3.1.x releases.

This seems to only happen on Workspace 1.6 and 1.7 that was upgraded from 1.6. I’m investigating it some more.

UPDATE:  Sybase is going to create a techdoc explaining this behavior.  This is somewhat expected behavior because of the older 3.1x Eclipse version.

Listen to this podcast

Mark Phippard, over at CollabNet, compiled a list of blog posts that are well worth the time to read.  A snippet from his “Subversion blog posts to read” blog post:

Computing the Differences Between Tags by Mark Phippard
In this post I show the new svn diff –summarize command and how you can use it to get a list of files that changed between two repository locations.

Authz and Anon Authn Agony by Mike Pilato
In this post Mike explains a difficult problem you can run into when you want to provide anonymous access but also have private folders within the repository structure.

Multiple Subversion Repositories? by Guido Haarmans
This post touches on the issue of having multiple replicated repositories to support globally distributed development. More specifically, why you may not really need this with Subversion as you do with other tools I will not mention.

Subversion LDAP Authentication with Apache by Jeremy Whitlock
Jeremy gives a primer on how to configure Apache to authenticate users via an LDAP directory, such as Microsoft Active Directory.

How Subversion Conserves Disk Space by Guido Haarmans
This is a high-level overview of how the Subversion repository stores your data. 

Mark is a well respected member of the Subversion community.  You can read more about him on his blog.

Listen to this podcast

jkeenan1 has asked for the wisdom of the Perl Monks concerning the following question:

Reputation: 28

At $Job, I am admonished, "Always develop in a branch. Never develop in trunk." So when I recently earned commit privileges to the Parrot subversion repository, one of the first things I did was to create a branch in which to work on my refactoring of some of Parrot’s build tools written in Perl 5.

The problem is: I’m spending too much time maintaining the branch. I seek the wisdom of the monks in figuring out how to use Subversion branches most expeditiously.

Let me describe the problem more precisely. At any given time, I’m taking a script executed by make and located in the tools/build/ directory, extracting its functionality into a new module placed in the lib/Parrot/ directory, and writing a test suite placed in the t/tools/ directory. While testing the new module’s subroutines, I also have need to read source code such as ops files found in the src/ops/ directory.

That may sound complex, but it really amounts to only a half of one percent of all the files and directories in the Parrot source tree. So of all the files in my buildtools branch, 0.5% are there so that they don’t hurt anything in trunk, while 95.5% might just as well be identical to the files in trunk — which means that I would like to keep them in synch with trunk as much as possible. (After all, a change in one of those files might affect the outcome of the tests.)

After reviewing the Subversion book, the only way I’ve found to accomplish this is this:

1. In my branch, call svn update to determine the version (let’s call the revision n).
2. Call svn merge -r 16803:n  https://svn.perl.org/parrot/trunk, where 16803 is the revision at which my branch was created.
3. Ideally, at this point I call svn commit and everything updates nicely. But in practice, I get all kinds of conflicts which have little immediate significance but which must be resolved for a commit to succeed. Examples: changes in file properties; conflicts in the MANIFEST. In other words, things that waste my time and don’t make development in my branch any easier.

In other words, I want to keep my branch reasonably up-to-date so that I can be assured that my own files will eventually commit to trunk correctly — but I don’t want to spend 15 minutes a night resolving spurious conflicts in the branch. How can I do this most effectively?

Thank you very much.

Jim Keenan

Read more on Perlmonks.org

 

Listen to this podcast