Re: Subversion migration schedule (new cut-off Fri 14 July?)

["James Henstridge" <james jamesh id au>]

On 05/06/06, Joe Shaw <joeshaw novell com> wrote:
> Hi,
>
> On Fri, 2006-06-02 at 20:22 +0200, Murray Cumming wrote:
> > I guess at the least we need to create the branches/gnome-2-*/ or
> > similar directories early, and tell people to put their branches in
> > their.
>
> With svn we definitely have a lot more freedom in how we set up our
> branches and tags.  So I think we should immediately limit that freedom
> by coming up with some conventions. :)  I propose the following:
>
> Assuming we have some project on the trunk with the URL like so:
>
> http://svn.gnome.org/trunk/project
>
> Tags, I believe, should be in per-project directories, like so:
>
> http://svn.gnome.org/tags/project/PROJECT_1_0_0/project
>
> We don't have to keep using the "PROJECT_1_0_0" convention for tags with
> svn, but I think we probably should for compatibility and
> predictability.
>
> Likewise, we should do similarly for per-project branches:
>
> http://svn.gnome.org/branches/project/project-1-0-branch/project
>
> But for GNOME-wide branches, we should use the higher-level directory:
>
> http://svn.gnome.org/branches/gnome-2-16/project
>
> (For these, though, we should probably migrate them to the more
> aesthetic and correct "gnome-2.16" name, since there are fewer and they
> are easy to predict programmatically.)

The suggested layout for multi-module repositories from the Subversion
book is actually:

 ./$project/trunk <- the mainline for development
 ./$project/branches/$branchname <- a branch of the project
 ./$project/tags/$tagname <- a tag of the project

For cases where there is only a single module in the repository, they
recommend leaving of the "$project/" bit at the start of the paths.

What benefits does your layout give over the recommended layout?  It
looks like it would add complexity without making things easier to
understand.

James.