Equivalent to svn tags?

Matthew Tylee Atkinson mta at agrip.org.uk
Mon Oct 29 00:52:56 GMT 2007


John Arbash Meinel wrote:
> Certainly for someone coming from SVN, you have everything and the kitchen sink
> in a single repository. (Setting up a new one is difficult, so you sure aren't
> going to do it more than once.)

This is *exactly* my current point of interest.  We have a repository
that looks like this:

tags/
    0.2.0/
	. . .
    0.2.1/
	. . .
branches/
    accessiblequake/
        . . .
trunk/
    audioquake/
	. . .
    zq-repo/
	qc/
	    . . .
	zqcc/
	    . . .
	zquake/
	    . . .
    mauth/
	. . .
    sns/
	. . .
    ldl/
	. . .

Each thing under trunk is a separate module of the overall project.
Each thing under zq-repo is actually a fork of an existing project that
was made due to their development infrastructure temporarily failing and
our lack of time and interference from IRL events (hopefully we'll be
able to merge back at some point).

I'm now tasked with having to split these up into separate projects an
Launchpad, which means thinking about them in a radically different way.
 Some are highly related, so I expect I will put them as top-level
directories in individual bzr branches.  I think I may go for the
following layout.

AudioQuake Launchpad Project:
    trunk branch
	audioquake/
	    . . .
	zq-repo/
	    . . .
    legacy accessiblequake branch

Level Description Language Launchpad Project:
    trunk branch
	<files from /trunk/ldl/ in SVN>

Stats and Servers Launchpad Project:
    trunk branch
	<files from /trunk/mauth/ and /trunk/sns/ in SVN>

I'm not seeking to waste anyone's time on offering advice on our
structure (you've already helped a great deal and this isn't strictly
``your job'').  I hope, however, that this post may (a) demonstrate the
radical change in our structure that will be necessary to properly open
development and use Launchpad+bzr and (b) may be of use for others in
future.

All of this has certainly given me an insight into the debate between
shared storage and development freedom -- as a CompSci by training, I
like the idea of /not/ branching left right and centre for efficiency's
sake (so tags rock) but as a Free Software type, I love the freedom this
gives everyone (from easier repo setup to developmental freedom)!  Like
pretty much everything else, it's a balance [that your posts are helping
me understand].

One very interesting issue in all of this is how the projects may evolve
in future -- I see no reason to force them to be developed to the same
schedule and am very keen to see exactly how they pick up an are taken
forward by whatever parties take an interest in them.  Furthermore, this
decoupling appears to be in the spirit of D[RV]CS and I feel that it is
therefore the right way to continue.

best regards,


-- 
Matthew Tylee Atkinson <mta at agrip.org.uk>



More information about the bazaar mailing list