Work-Related Grumble

[cjsmith]

I officially hate SVN.

(Don't get me wrong; it's probably great for power users and people who never merge to/from a branch more than once or twice. Many thanks to preedmozblog, by the way, for pointing me at a tool that might replace my entire whiteboard for branch merge management. The problem I have with SVN is that when not everyone is a power user, or not everyone knows to track merges on their whiteboard, you get real trouble.)

Comments

[530nm330hz.livejournal.com]

I assume SVN = subversion? Is it much worse at branching than cvs is? I ask because we currently use cvs at work but some people have been making noises about switching to subversion, and if that will be bad then I should know to bother to object.

[ken_r]

For the most part I think it's a lot better than CVS. But if you need to do lots of merges between lots of branches, you probably at *least* want something like svnmerge on top of it (or svk?) to track what's been merged where.

At work, our merging isn't that hairy. (And for the most part only the release manager does merges to release branches, and other branches tend to be developers' private branches.)

[530nm330hz.livejournal.com]

Ok. Our merges are pretty straightforward here --- generally bugfixes that got made on a post-release branch that need to be applied to the mainline as well, and occasionally a private developer branch. Thanks for the clarification.

[cjsmith.livejournal.com]

Sorry I vanished for a bit there. Yes, svn doesn't have to be awful, as long as you're not implementing a large tree of branches (with frequent cross-merging) that's much better suited to a full-time release engineer and an installation of Perforce. Sadly, we're trying to do just that.

[tytso.livejournal.com]

There are other tools such as Mercurial and git that are much better at handling a large number of branches and merging work done in topic branches down into one or more release branches. The problem of course is this requires retraining the entire development population, which is often an impractical proposition.

[ken_r]

There's one or two branch-related things I haven't figured out how to do as efficiently with SVN as with CVS.

1) "What branches/tags were made after this patch?" (Which probably should really be, "Which branches/tags include this patch, either by branching after it was checked in, or by merging it in?")

2) "Did branch X include this patch?"

You can go through the logs of the branch(es) and trunk and figure them out (well, maybe not which branches got a patch applied later, unless you set up some careful conventions regarding log messages), but with CVS, you could look at the version numbers for the branches and tags right in the same log.