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

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

On 06/06/06, Joe Shaw <joeshaw novell com> wrote:
> Hi,
>
> On Tue, 2006-06-06 at 12:25 +0800, James Henstridge wrote:
> > 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
>
> If we're using separate repos for each module, then my proposal doesn't
> really apply.  Other than very high revision numbers and the ease of
> moving a project repository off of gnome.org to somewhere else later,
> what are the benefits of multiple repositories?

You'd have to ask Ross about why we're using multiple repositories.

There definitely are benefits to hosting multiple projects within a
single repo.  Subversion doesn't really handle interactions between
repositories so code in separate repos are quite isolated.  It is also
less effort to add a new module to a repo (compared with creating new
Subversion repositories, which will probably require sysadmin
intervention).

On the other hand, multiple repositories probably scale better since
there will be less lock contention.  I'm not sure how much of a
problem lock contention would be though.

> > What benefits does your layout give over the recommended layout?  It
> > looks like it would add complexity without making things easier to
> > understand.
>
> 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.

> The main benefit is that you could check out the whole of gnome 2.N at
> once, rather than knowing what modules to check out and doing so one by
> one.  For an automated tinderbox-like system, you could drop a single
> file at the root which lists the order in which to build the modules,
> and then you don't have to worry about *any* synchronization of the
> module list with tools outside of svn.

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 seems that checking out one of these repo-wide "gnome 2.N"
directories would end up pulling either too many or too few modules
for any particular use.

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.

James.