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

[Joe Shaw <joeshaw novell com>]

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
        
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.

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

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.

> 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.

Joe