[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: trunk/ vs branches/ repo dirs

From: Tor Ringstad <torhr_at_pvv.org>
Date: 2007-10-23 02:02:30 CEST

> 1. Why is trunk so special? Any really good reasons to not do the
> subdir-by-branch scheme?

At my site, we chose the standard trunk/branches/tags TLD structure
simply bacause (to us) it seemed like the most straight forward way of
mapping CVS concepts to Subversion. I agree that your suggested scheme
has a certain elegance; assumedly you're thinking that the "trunk" is
just the "root branch" in a "tree" of "branches". I have to admit that
I never thought of this scheme when we made the decision about our
TLDs, but I doubt it would have mattered. However, I have no real
arguments against it, it's just that it looks kind of complicated and
over-engineered, and definitely unconventional.

> 2. Are you adding any categorization to your branches/ TLD?

Not a lot. We don't really care if it gets a bit cluttered there. All
we have is /branches/personal/<username> where people create their
branches for work on a personal level; smaller features, bugs, etc.
In that namespace, people can organize their stuff exactly as they
feel, clutter is not a public issue. The /branches dir is reserved for
"officially sanctioned branches", which is mostly stabilization
branches, as well as a few "major feature branches".

This is a very simple scheme, but it works well for us. I'll have to
add, though, that we don't use branches aggresively, and we don't have
a complex branching structure or any complex flow of changes.

- Tor Ringstad -

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 23 02:02:59 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.