Minority Opinions

Not everyone can be mainstream, after all.

VCS Complaints

leave a comment »

When I think of everything I had to learn for my first job, it’s somewhat amazing that I survived the summer at all.  In addition to Perl, emacs, pine, and HP-UX, I first used CVS there.  Fortunately, my commits were limited to a few files that never moved, and were rarely edited by anyone else.  Only later did I discover its warts.

Fortunately, “later” happened to be within the lifetime of Subversion, which soon became my repository of choice, both for SourceForge projects and later, when I had my own server, for a few personal projects.  There might be some reason to choose CVS over it, but I can’t think of any.

A few years later, I’ve convinced a new employer to start versioning their code for real (instead of slapping dates on backup copies of random files).  It was there, after putting another year or so of a full team’s work into one repository with a few major branches, that I discovered why people had been talking about distributed systems.

Subversion sucks at merging

At one point, we wanted to pull pieces of an old broken project into our main successful one, so we started a branch for that.  Once the branch looked good, we examined the differences between it and the trunk, and started merging things back and forth.  Each time, I ended up as the one deciding which revisions to cherry-pick, ensuring that the range appeared prominently in the commit message.

It seems to have gotten better lately, with some third-party tools and some internal support from the svn:mergeinfo property, but the whole experience led us to strongly consider switching.

Bazaar sucks at branching

Since I was more or less in charge of the repository server, I was the first to experiment with different bases for it.  Almost immediately, I was struck by the inability to convert an entire repository at once.  Instead, I had to convert each branch individually, because Bazaar’s idea of a branch always has a working copy.  Even on the server.  Sure, there’s the idea of a shared base directory to save disk space, but every new branch would mean setting up a new directory on the server, and I didn’t want to deal with that.

I had also gotten used to switching branches in my own working copy, but Bazaar’s model simply doesn’t allow such a workflow.  Given that one of our primary motivations for switching would be the ability to use topic branches, the whole experiment died almost immediately.

Mercurial sucks at pulling

Meanwhile, I had been using Mercurial to store some of the files in my home directory, so they could be synchronized between the various machines I used.  Of all things, it’s the KeePass password database that causes the most trouble, because it can’t be merged programmatically.  I’ve gotten a little paranoid about pulling new revisions from my “central” repo before generating a new password, and checking it in as soon as possible, but frequently get bitten by some other minor change.

If any tracked file anywhere has outstanding changes, I can’t pull any changes at all from the server.  I haven’t even figured out how to check whether the server has any changes to pull.  Granted, it’s good practice to commit changes as soon as possible, but it can seriously interrupt my flow to deal with the little things that may have crept into various config files over time.

Or perhaps that’s the fault of using the fetch extension, instead of the standard pull.  I started using it after a few too many dire warnings about multiple heads; given that I’m the only one committing to this repository, I always want the upstream changes, anyway.

Git  sucks at committing

Those issues led me to accept a colleague’s git activism for our new version control system.  I had initially been hesitant due to experience with its early days, back when it expected other people to provide the porcelain.  In particular, I experienced actual data loss when switching branches through the cogito porcelain with uncommitted changes in a new file.  Perhaps I shouldn’t be so hard on Mercurial for preventing me from doing the same thing, but it could certainly be nicer about it.

I have to admit, the git commands have improved dramatically.  The little things like automatic paging and colorization set many of them head and shoulders above the competition, even where plugins or aliases can compensate.  But every time the commit command complains about the lack of staged changes, I get a little bit irritated.

The worst part is that I have occasionally used the index to good effect, so adding the -a parameter by alias did more harm than good during a short experiment.  It’s often not what I want anyway.  But when I have just diffed a single change in a single chunk of a single file, I want commit to just work.

Perhaps someday I’ll write the necessary magic.


Written by eswald

5 Jun 2012 at 10:39 pm

Posted in Technology

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s