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

[Ross Golder <ross golder org>]

On Mon, 2006-06-05 at 12:52 -0300, Johan Dahlin wrote:
> [..]
> > http://svn.gnome.org/trunk/project
> [..]
> > http://svn.gnome.org/tags/project/PROJECT_1_0_0/project
> [..]
> > http://svn.gnome.org/branches/project/project-1-0-branch/project
> [..]
> > http://svn.gnome.org/branches/gnome-2-16/project
> [..]
> 
> All of these urls assumes that there will only be one repository for all the
> modules/projects. It is not possible to branch between repositories.
> 
> It seems like (judging by the revision numbers found on svn.gnome.org) that
> it is currently done by having one repository per module/project.
> 

Indeed. One repository per module is the way I have been doing it.

> I'm in favor of having one big repository, which would allow this kind of
> aliasing. The main disadvantage is the big revision numbers (6 or 7 digits).
> 

I can see there are plenty of good arguments for and against the three
main approaches (single, multiple and mixed) described in the 'Choosing
a Repository Layout' section of the manual
<http://svnbook.red-bean.com/en/1.1/ch05s04.html>.

However, I still feel that the multiple repositories approach will work
best for GNOME. I think being able to import/export and control (e.g.
hook scripts, revision numbers, branches/tags etc) at a module level is
the best approach. Eventually most monolithic things get broken down and
modularised anyway, so IMHO we might as well start broken down (pretty
much as we are now) and build up.

The way the migration script works at the moment is that all modules
will have a separate repository, with their own hook scripts etc. I
particularly want this feature, so I can set up automatic e-mails for
*only* commits on modules for which I am maintainer, without having to
subscribe to the dirty great 'svn-commits-list'. Also, the migration
script adds a call to a global shared hook-script, containing the
'svn-commits-list' hook among others.

Also, it means projects can move to/from the GNOME subversion service
more easily (without having to integrate/extract themselves from a
monolithic repository). And, if one module gets corrupted or something,
the whole repository doesn't become stalled.

As for project-wide release tags (e.g. GNOME-2-14 etc), I can see that
it's a tempting feature, but would it really give us a day-to-day
advantage over individual repositories all using a common branch-name
conversion to identify them? I'm imagining that a simple 'for...' loop
for a given set of repositories would suffice in most cases. Also,
historical project release branches/tags will probably be fragmented
anyway where the different module maintainers haven't all used the same
branching/tagging case and underscore/hyphen conventions. I'd be
interested to hear the release team's view on whether a monolithic repo
would really make their lives much easier.

Anyway, if I'm way off the mark, and people really do think a monolithic
repository (or even a mixed one, where we have a repository per group of
packages) is the correct way forward, I'll happily cancel the upcoming
migration again until someone can come up with a more suitable
strategy :)

Cheers,

--
Ross

> Johan
> _______________________________________________
> gnome-hackers mailing list
> gnome-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-hackers