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

["James Henstridge" <james henstridge gmail com>]

On 07/06/06, Joe Shaw <joeshaw novell com> wrote:
> Hi,
>
> On Wed, 2006-06-07 at 00:22 +0800, James Henstridge wrote:
> > On 06/06/06, Joe Shaw <joeshaw novell com> wrote:
> > > I don't really see any added complexity in there.  It's essentially the
> > > system we have today with CVS.
> >
> > Really?  The layout described in the Subversion book seems like a
> > closer analogue to what we do in CVS.
>
> Are you referring to this?
>
>         http://svnbook.red-bean.com/en/1.1/ch04s07.html

Yes.  That page of the book also links to this page, which goes into a
bit more detail:

   http://svnbook.red-bean.com/en/1.1/ch05s04.html

> Assuming one large repo, the only difference between my proposal and the
> book's is that there is an extra directory level in the branches (or
> tags) directory for each project.  That way one doesn't have to wade
> through every tag or branch name for every project.  In that sense it's
> more like CVS now: tags and branches are private per module.

You are suggesting having toplevel trunk, branches and tags
directories in the repository, while the book suggests having separate
trunk, branches and tags directories under each project root in the
repository.

A lot of the differences between the suggested layout and your
proposed layout seem to stem from trying to make that layout usable
(e.g. keeping the branches directory manageable).

> For example:
>
>         /repos/calc/branches/my-calc-branch
>
> would most likely in an equivalent single repo setup be:
>
>         /repos/branches/my-calc-branch
>
> My proposal is:
>
>         /repos/branches/calc/my-calc-branch

If "/repos" is the Subversion repository, then the book actually
suggests you use:

   /repos/calc/branches/my-calc-branch

(so everything related to "calc" is under a single directory in the repository).

> That way, when you really want to see just the calc branches you can go
> to /repo/branches/calc and not also see all the "paint" branches.
>
> The one exception is for any repo-wide branches, like a GNOME release.

I am not convinced that there are many benefits to storing the all
Gnome 2.N branches under a separate directory.  It would effectively
hide them when browsing through the other branches of each individual
module.

> > Who would be allowed to create branches in this repo-wide "gnome 2.N"
> > branch directory?  Only stuff that is part of desktop and developer
> > platform? Everything that creates branches to target particular Gnome
> > releases?
>
> It could require a change in workflow, perhaps negatively.  People would
> have to branch at release time, rather than delaying it until they're
> ready for unstable development.  And checking into the branch and the
> trunk is a PITA.  But it's probably something that warrants discussion.
>
> But to answer the question, I'd assume that module maintainers who
> branch now would simply copy their modules into the branch directory.
> Perhaps it could be done by someone on the release team at release-time.
>
> > It is also worth noting that there will always be important parts of
> > the Gnome module stack that are outside of our Subversion repository.
> > For example, the recent GTK printing work depended on new features in
> > Cairo.  With your system without maintaining an import of cairo into
> > the Gnome Subversion repo, which would be a maintenance nightmare.
>
> True, but any automated build tool needs to handle out-of-tree
> dependencies anyway.  Reducing the maintenance for our part somewhat is
> preferable to reducing it none, IMO.

Well, I plan to continue maintaining the Gnome module set definitions
for jhbuild in Subversion, which is essentially the information you
propose storing in the repo.  It is fairly agnostic to the exact
layout used in the repo, so wouldn't really benefit from a gnome
release-wide branches subdirectory.

James.