Month: May 2009

In the version control world, I’m a big fan of perforce. I first became a fan when I saw how fast it was–it can perform checkouts of gigabyte-sized repositories extremely fast. I also really liked the perforce workflow–changelists are the “normal” way of working. However I started to love perforce when I began playing with it’s branching capabilities. It’s ridiculously easy to create and integrate branches, and they have wonderful tools for helping you understand branches.

At my new workplace we’re on svn, and while I wouldn’t say I “hate” it… That’s a pretty strong word… I am “very displeased.”

Speed isn’t so much of an issue here because we’re only dealing with megabyte-sized repositories, so a minute or two to checkout ~100mb or so isn’t too painful. The svn workflow has taken some getting used too. Nobody works with svn changelists–there are no good tools for managing changelists so it’s wasted effort. It’s easier to just do another checkout of the repository and work in there. Since our repository here is relatively small this is no big deal. (I couldn’t imagine what it would be like with a larger repository! Yikes.)

Branching in svn is downright painful. I suppose if you had nothing but text files running on one operating system and everything was in one flat directory structure you might say, “What are you talking about? It’s so easy!” but so far that hasn’t been my experience. Here are the problems I’ve encountered:

• Merging subdirectories instead of merging from the root. Apparently this is a known “no-no” according to the Subversion book. I made the “mistake” of merging a subdirectory a few revisions back and now whenever I merge from the root it wants to re-merge all the files in those subdirectories every single time. It marks their properties as modified even though they’re not being changed. Maybe this is just svnmerge.py being diligent but it’s annoying to see this massive list of files every time I merge, when really the “meat” of the merge is in just a handful of separate files. Weak sauce.
• Merging eol-style properties. There’s a known bug in svn 1.5.0-1.5.4 where if you make eol-style changes to a branch and you try and merge that to another branch you may get a “inconsistent newlines in /tmp/tmp” error. I encountered this and the only way I could figure out how to get around it was to upgrade to svn 1.5.6, make the eol-style changes in the branch, commit, then perform the merge. I then had to downgrade back to svn 1.5.1 because 1.5.6 couldn’t deal with the branched subdirectories I mentioned previous. I’d see an “Error reading spooled REPORT request response” message when it got to those subdirectories that had been previously merged.
• Merging inconsistent newlines. Really? This problem arrises because svn stores on the server whatever newlines you give it. I can’t think of any reason why the svn server would not store files as ‘eol-style=native’ on the server by default. It seems like storing the client’s newline format on the server is an exceptional case, not the common case. It’s irritating to have to merge newline inconsistencies.

I miss perforce. Somebody needs to develop “poorforce”, a cheap version of perforce. 🙂