[Rt-devel] Relabeling subversion branches

Michael S. Liebman m-liebman at northwestern.edu
Thu Jul 1 14:57:56 EDT 2004

On Thu, Jul 01, 2004 at 11:36:21AM -0400, Matt Disney wrote:
> Jesse Vincent wrote:
> >Should the various stable/testing/experimental branches have their major
> >version numbers as part of their pathnames?  Is this new plan actually
> >better than what we do now? Is there a better model we should be
> >following that will be more useful to the general public?
[snip happens]
> rt/trunk (if applicable)
> rt/branches/rt-3.2
> rt/tags/rt-3.2.0 (minor release number)
> rt/tags/stable
> Another example:
> rt/branches/rt-3.0
> rt/tags/rt-3.0.11
> rt/tags/maint

The way the Subversion has there project structured would work out something like this:

rt/trunk          (current development)
rt/branches/3.0   (maintenance)
rt/branches/3.2   (maintenance)
rt/branches/3.2.1 (stabilization before release)
rt/tags/3.0.11    (hands off)
rt/tags/3.2.0     (hands off)

That seems to result in the least amount of backporting/merging, but
may only work because of their strict rules on API/ABI compatibility.

> Also, as I indicate above, I would tend to believe that:
> 1. "trunk"=="stable" instead of "trunk"=="maint",

I'd do it the other way.

> 2. "stable," "maint," "testing", etc... should be tags not branches,

I'm not sure how necessary these are since renaming currently makes
things difficult unless you are using SVN HEAD/1.1 or svk.

> 3. in general, the public should be steered toward tags and away from
>    branches, while branches would be more useful for developers.

Completly agree.

> One downside of my suggestion is that you would have to create at least 
> 3 or 4 copies everytime you roll a release.

The Subversion project release procedures also do that and I find that
it's a good thing.

Michael S. Liebman                      m-liebman at northwestern.edu
"I have vision and the rest of the world wears bifocals."
        -Paul Newman in "Butch Cassidy & the Sundance Kid"

More information about the Rt-devel mailing list