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

[dr-scott.livejournal.com]

A couple of neurons fired while reading this, but I was able to suppress them. :-)

[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.

[apparentparadox]

Are you using tags as they recommend in the FAQ?

Or, does that count as "power user"?

[cjsmith.livejournal.com]

Definitely power user. Several of the people here don't think you need to remember this stuff because "Subversion keeps track of it". Heck, we're having a glorious time merely trying to use the same version of Subversion client on Linux, Mac, Windows, and Cygwin. I can't count the number of times I've had to blow away my source tree because "This client is too old to work with working copy '.'; please get a newer Subversion client."

So yeah, maybe "power user" is a little bit overstating the case, eh?

[eichin.livejournal.com]

That FAQ item is probably one of the clearest bits of evidence that svn is a pretty good toolkit for *building* a version control system, but it really isn't a complete breakfast. (We use it very heavily... but anyone who wants to be clever typically comes and bugs me-as-releng, either beforehand, or after screwing it up once - and I have this growing pile of tools I've written to do actually releng tasks.) (and no, CVS "isn't even" a useful toolkit for this.)

I've heard rumours that if we used perforce, the release engineer would be happier (and everyone else would be in pain :-) but I haven't dug further; we're certainly not leaving svn any time soon, especially having started with CVS.

(I think svk is interesting as a tool for doing short term projects off-trunk and *not* checking them in, ie. gives developers an alternative to branching at all... but you need more discipline in that model, especially since noone's reviewing your commits until you're done...)