subversion

[Kent Borg]

On Wed, Aug 09, 2006 at 04:50:33PM -0400, Stephen Adler wrote:
> Anyone with experience using subversion, if you 
> could comment, I certainly would like to read them.

In a previous life I converted an employer to CVS and in my current
job I set up Subversion (replacing *NO* source code control, if you
can believe it--and it is not a new company).

I like Subversion, but I have one serious gripe: it is too general
purpose.  It will do everything you need for source code control, but
it doesn't have the *specific* facilities you need.  Want to tag a
version?  There is no "tag" command.  Really.  And that is a feature!
To tag something you make a copy (which is efficient, using something
like links).  Want to make a branch?  Again, there is no facility for
branching your project.  And again, this is a feature.  The correct
way to do it?  With another copy.  (Again, an efficient copy.)  You
can also make copies in subversion, the new copy will be under control
and its history will reflect where it came from.  

So what is the difference between a tag and a branch and a copy?
Nothing, not as far as Subversion is concerned, it is all a matter of
how you use the two different copies.  Want to start making changes to
your tag?  Fine.  Subversion will let you, and you now have turned
your tag into a branch.  And if a coworker doesn't notice and quickly
grabs the thing named "releases/version2.1.3" s/he will get the most
recent version of "version2.1.3" not the original "version2.1.3".

Out of the box, Subversion thinks they are all the same: tag, branch,
or copy.  Very scary.

It is great to have a general purpose tool, but sometimes it is nice
to have a specialized tool (for, say, source code control), that leads
you in the right direction.  A tool that anticipates the N things you
are likely to want to do, and provides a way to do those N things, is
very nice to have.

Subversion has made a religious choice that they will not provide the
facilities you need for source code control, not if a disciplined use
of their general purpose features will accomplish the same thing.  I
think this is a mistake.  It is really easy to screw yourself with
Subversion by doing something dumb at the beginning (when you don't
yet know what you are doing).  A targeted tool is nice because the
naive user will follow his/er nose and get a conventional result.  It
is only later, when the more subtle feature is needed, that the now
not-so-naive user digs deeper for the extra feature.  In the case of
the general purpose tool you need to make wise decisions up front in
how you choose to use the tool.

Don't get me wrong, Subversion has been valuable.  And other than
maybe putting too many things in a single repository (multiple
repositories would have been smarter--I think), I don't think I have
been burned.  But if someone commits new stuff in the "releases"
directory, I probably won't notice.  Yes, Subversion has facilities to
prevent such things (probably to have me write a pre-commit hook
script), but I wish that sort of thing were built in.  The idea of a
"tag" is a pretty fundamental part of source code control to leave
out.

The day a less elegant (i.e., more focused) source control tool comes
out that has the main features of Subversion I will be badly tempted
to change.  If it also supports distributed repositories (which
Subversion does not), then I am probably wanting to move on fast.


Sorry to be so slow in responding to this thread.  I get behind in my
e-mail.


-kb, the Kent who wouldn't dare post such things on the Subversion
mailing list, for they would flame him to a crisp.