kentborg at borg.org
Fri Aug 18 10:19:36 EDT 2006
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?
More information about the Discuss