subversion

[Kent Borg]

On Fri, Aug 18, 2006 at 08:20:23AM -0400, David Kramer wrote:
> You know, I hear this all the time, but nobody has every been able to
> tell me what's so "scary" about it.  What do you think the difference
> should be between a tag, a branch, and a copy?

To my feeble/traditional/CVS-polluted mind:

  tag      Symbolic name for a version.  More descriptive than some
           raw number, but just as stable.  There should be no more
           risk of the version referenced by the tag changing than the
           risk of a version changing when referenced by a version
           number.  A tag is a cheap operation that makes it easier
           for an organization to know what is going on.  A good tool
           should encourage tags.

  branch   Something that has obvious and durable ancestry, something
           that is expected to change as work is done on that branch.
           It should be a follow-your-nose operation to merge in again
           to the line it came from.  A branch (forking the code) is
           an expensive thing for an organization that makes it harder
           to know what is going on.  A good tool should not encourage
           forking your code.

  copy     A free-form thing.  It is good to know where it came from
           if you bother to look, but it doesn't necessarily have any
           ongoing relationship to that source.  A good use for a copy
           is when starting work on some new project, lifting work in
           the form of a copy as a starting point, but then evolving
           on from there independently.

Subversion is clearly powerful enough to implement these, but
out-of-the box it has no concept of tag or branch, everything is a
copy.  Tags and branches are things that one must build by admonishing
users to follow a set of rules/conventions, or by using the tools
Subversion supplies to build higher level features.

The scary part: If you don't have these ideas clear in your usage of
Subversion you can end up with tags that don't stand still, branches
where you are not clear what the key versions are when you want to
merge back into your main line, and a zillion other mysterious copies
proliferating for no disciplined reason, ready to explode if someone
makes the mistake of typing "svn co http://mysvnserver/svn" and
checking out your root.

Yes, in a well set up system all of these things can be dealt with,
but out-of-the box Subversion is not a "well set up system".
Subversion is a powerful toolkit that requires further work before it
is "well set up".  Don't get me wrong.  I have no objection to general
purpose tools, but sometimes (to pick an extreme example) I would
rather be handed a spreadsheet than be handed a C compiler.


After my rant yesterday I was thinking that Subversion is really prime
to have a ready-to-go source code control system layered on top of it.
Then, in cleaning up other old e-mail I noticed someone on the
Subversion mailing list mentioning SVK.  Ah, that might be what I
want.  (When I originally installed Subversion SVK wasn't yet at 1.0,
too scary a place to trust with source code.)

Anyone have experience with SVK?


-kb