[geeks] Subversion trunk and branch methods

[Charles Shannon Hendrix]

I'm starting to make the move to Subversion, and now that I've gotten
familiar enough to start using it, I have to make the first big
decision about how to organize the repository.

There are two ways that are common.  The first is recommended by the svn
developers:

Create a branch, tag, and trunk directory in the repository.  Projects
are stored below those, like so:

	trunk/project1
	trunk/project2
	branch/project1
	tags/project2

Some references say don't bother with tags, but that's the gist of it.
They recommend putting ALL project mainlines under trunk, ALL branches
under branch, etc.

The other common method is to create a directory for each project, and
put individual trunk and branch directories under that, like so:

	project1/trunk
	project1/branch
	project2/trunk
	project2/branch

...and so on.

At least so far, I don't really understand the ultimate difference
between the two approaches, and unfortunately neither "side" does much
to explain the reason for their method.

So, I thought it might be a good topic for discussion, and maybe some of
you out there with longer-term Subversion experience can talk about what
you do, especially if you have used one or both of the methods described
above.

Random notes and observations:

I chose Subversion after about 2 years of looking at alternatives to
CVS.  The primary reason is because it seems to have a greater following
than anything else, remains familiar enough, and seems to finally be a
project with a lot of user momentum (after years of beta).

Subversion's one *HUGE* flaw, IMHO, is not having per-project revision
numbers.  The svn developers say it is because of an unhealthy fixation
on revision numbers, but that's not the problem.  Number one, if I do 10
edits of proj1 and 800 of proj2, svn tells me proj1 is version 810 upon
update.  That's an obvious untruth.  Yes, the number applies to the
entire repository, but then you have to ask, what happened to the other
790 revisions of proj1?  No matter how you look at it, it would make a
lot more sense and be a lot more useful if revisions tracked individual
projects.  But, that's a lost battle and I guess I can accept it, even
though I hate it a great deal.

Subversion is one hell of a lot better than CVS at almost everything CVS
does, and does a lot that it either can't, or can only do with a big
mess.

Subversion is faster.

Subversion is more cumbersome to use from the command line, and its
interface, quite frankly, sucks.  That's one area where they didn't
improve on CVS, and in some ways it is even a step backward.  This is
particularly true when doing a whole lot of branch patching and merging.
But, it does work very well once you get used to it.

Subversion should not be prone to the data lossage bugs in CVS (due to
its use of RCS underneath).

Despite how I hate the global revision number, it is damned nice to have
a single revision for all of a project's files for a given release.














-- 
shannon "AT" widomaker.com -- ["Meddle not in the affairs of Wizards, for
thou art crunchy, and taste good with ketchup." -- unknown]