[geeks] Subversion, two weeks of usage

Charles Shannon Hendrix shannon at widomaker.com
Sat Aug 26 09:58:58 CDT 2006


Regarding Subversion for revision control:

In the end, now that I've used it for a few days, it seems that the
layout of <section>/<project> makes very little sense, and
<project>/<section> makes a lot more sense.

So I picked my layout like this:

	<project>
		trunk
		branches
		tags
	<category>
		<project>
			trunk
			branches
			tags

...and so on.  Makes a lot more sense to me anyway.

Subversion does everything by using cheap copies, by which I mean a copy
is only a notation in a revs file until you actually change something.
This means copies are very inexpensive, so you can use them extensively
to come up with almost any kind of management system for your projects.

What happened is that CVS did everything with revisions and property
tags, and that's difficult to code.  Other systems which do this are
complicated and prone to problems.  The subversion team just decided to
not try and tackle that problem at all, and use tree copy and merge
operations instead, which neatly duplicates the exact same thing as
branches and merges in other systems, plus you can use it for all kinds
of other uses.

Hated the idea at first, but now I love it after using it a couple of
weeks.

Some examples:

Let's say you have a project, a database class, and you have it stored
in dclass/trunk, your main development tree.

You want to release the current version as 1.0 and give it to your
users.  This is how you do it.

% cd ../
% svn cp trunk tags/release-1.0

...and that's it.  Instant release revision.  Subversion tracks all
copies just like it was a change to a file, and all commits and versions
are completely atomic.

Now if you ever need to return to version 1.0 for a bug fix, the
operations are pretty easy even many revisions later.

% svn cp tags/release-1.0 branches/release-1.0-memory_fix

You make changes and decide the client should check it out.  He tests it
and it is OK, so you do this:

% svn mv branches/release-1.0-memory_fix tags/release-1.0a

...and this becomes a bug fix release for 1.0.

If you think the change needs to be in your mainline, now at version
3.2, you merge them:

% svn merge tags/release-1.0a/<fixedfile>@<VER> trunk/<fixedfile>@<VER>

...where <VER> are the revisions that need to be merged (since they
won't always be HEAD, subversion refuses to operate unless you tell it
which revisions to use.

That's just one example and naming system of course, you could do
whatever you wanted.

The bottom line is that in subversion, copies are cheap, so you use them
for everything.

Also worth nothing is that all operations in subversion are O(1)
operations, so you generally don't pay a heavy price for any of them,
relative to the work done.

By contrast, some operations in CVS are horribly inefficient.

There are still things I don't like about subversion, one of them being
that merges are not tracked.  They appear to subversion as just local
changes to the current path.  It is a future feature that I hope arrives
soon, as I want my merges documented.

There are other things too, but overall I like it well enough to make
the move away from CVS.

I've spent years on various revision control systems, and none of them
really do what I want all the time.  Even expensive commercial systems
have been a real disappointment.  In fact, most of them are nowhere near
as good as CVS, and certainly not Subversion.

PVCS is, IMHO, complete crap and I can't imagine why anyone would
recommend it.  It's buggy, loses data, and has terrible performance, not
to mention it doesn't support a lot of platforms.  It's UNIX support is
horrible, and it is frequently excruciatingly slow even on the simplest
tasks.  

Microsoft's revision system I also thought was crap.  It was interesting
in some ways, but overall I didn't like it, and of course it does me no
good on UNIX and other systems.

Bitkeeper is not bad, but does a few things I didn't like, and I can't
afford it.  It's licensing is downright wierd.  However, it does have
some nice remote repository features.  You can get the same thing in
Subversion by using svk on top of it.

-- 
shannon "AT" widomaker.com -- [4649 5920 4320 204e 4452 5420 5348 5920 4820
2056 2054 434d 2048 4d54 2045 204e 5259 4820 444e 0a53]



More information about the geeks mailing list