[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn modules (was Re: Features and release dates)

From: Zack Weinberg <zack_at_codesourcery.com>
Date: 2002-05-02 01:20:07 CEST

On Wed, May 01, 2002 at 11:26:37PM +0100, Philip Martin wrote:
> > > This is more general-purpose and much more flexible than modules.
> > > What does everyone think?
> >
> > If I do not want to use doctools main trunk version, but a bug fixed and
> > stable version (tagged with DOCTOOLS_STABLE), how should I create the link
> > then?
> Well, in Subversion a "tag" is simply a cheap copy, so
> svn ln http://foo/repo/tags/DOCTOOLS_STABLE/ .

Let me ask a related question. This is going to require a fair bit of
context, please bear with me.

The GNU toolchain projects (GCC, GDB, binutils) are seriously
considering moving to Subversion once it has enough functionality and
stability. Currently GCC has one CVS repository, and GDB+binutils+a
bunch of other stuff share another. However, notionally it's all one
big source tree, and there are a lot of files which are shared between
the two repositories.

It would be sensible to merge the two when we switch to Subversion -
the basic reason it hasn't been done already is that it's considered
too risky. However, we want to do this in a way that lets people keep
working the way they have been. One key issue with that is the
ability to tag just a subgraph of the file tree. We want people who
check out the GCC 3.1 release label to get nothing but GCC 3.1; if
they got anything more, they might incorrectly think that the rest of
the software had been through a proper QA cycle when it hadn't.

So suppose I lay out the merged repository like so:

       gcc/trunk/gcc == ../../../complete/gcc
                 libiberty == ../../../complete/libiberty
       gdb/trunk/gdb == ../../../complete/gdb
                 libiberty == ../../../complete/libiberty

Then I want to be able to 'svn cp' gcc/trunk to gcc/3.1-branch, check
in patches to gcc/3.1/gcc/whatever.c, and have whatever.c record a
proper branch in its per-file history.

I also want to be able to check out repo/gcc/3.1.0-release,
repo/gdb/5.1.1-release, repo/binutils/2.12.4-release, all into the
same directory, have something sensible happen with files that are
shared between the threee, and then do "svn up" later and have each
subset of files track the branch it was checked out from. You try
this with CVS and directories that are shared between the branches
tend to get confused which branch you want them on.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 2 01:21:21 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.