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

Re: Maintaining two vendor branches of a single program

From: Christian Daudt <csd_ob_at_daudt.org>
Date: 2003-04-08 19:19:27 CEST

On Monday 07 April 2003 12:06, John Goerzen wrote:
> Hmm, I think I see a couple of problems here, and I think it's my fault for
> not explaining in more depth:
> On Mon, Apr 07, 2003 at 11:40:04AM -0700, Christian Daudt wrote:
> > So method A is:
> >
> > <cd to linux-2.4.20>
> > svn import to vendor/linux/current
> By svn import here and below, I take it you mean something like
> svn_load_dirs that can handle diffs, added/removed files, etc?

Yup, I'm using svn_load_dirs

> > svn cp vendor/linux/current vendor/linux/vanilla-2.4.20
> > <cd to linux-2.4.20-ac1>
> > svn import to vendor/linux/current
> > svn cp vendor/linux/current vendor/linux/2.4.20-ac1
> > [repeat for other 2.4.20-ac]
> The problem with this is that it can't handle more than one tree. For
> instance, I may want to have 2.4.20-ac1, as well as the davem series, the
> benh series, and the aa series in my Subversion repository. With this
> method, I don't think I can do that.
> > <cd to linux-2.4.21>
> > svn import to vendor/linux/current
> This is the place where I take it you'd see the reverse patches, right?


> On the one hand, you're correct that that could technically be considered
> correct, but on the other hand, if the patches are coming back in with ac1,
> wouldn't that make merging with svn merge difficult?

I think that your concern here is if it wouldn't be better to have all of the
ac branches sequentially imported even across vanilla releases, and then just
merge the vanilla deltas on to the parallel ac tree. I don't think so,
because usually 2.4.21-ac1 is truly based on 2.4.21, not on 2.4.20-acN, so
your import sequence should reflect that.
 Of course there are no guarantees, but even though 2.4.21-ac1 might contain
mods that where in 2.4.20-acN but not in 2.4.21 you have no guarantee as to
how similar they are syntactically, only semantically (if that).

> > svn cp vendor/linux/current vendor/linux/vanilla-2.4.21
> > [repeat for 2.4.21-ac]
> >
> > method B is:
> >
> > <cd to linux-2.4.20>
> > svn import to vendor/linux/current
> > svn cp vendor/linux/current vendor/linux/2.4.20/current
> > svn cp vendor/linux/2.4.20/current vendor/linux/2.4.20/vanilla
> > <cd to linux-2.4.20-ac1>
> > svn import to vendor/linux/2.4.20/current
> > svn cp vendor/linux/2.4.20/current vendor/linux/2.4.20/ac1
> > [repeat for other 2.4.20-ac]
> > <cd to linux-2.4.21>
> > svn import to vendor/linux/current
> > svn cp vendor/linux/current vendor/linux/2.4.21/current
> > svn cp vendor/linux/2.4.20/current vendor/linux/2.4.21/vanilla
> > [repeat for 2.4.21-ac]
> >
> > I've been using a similar method (only I'm tracking Suse/Redhat branches
> > from vanilla kernels) and it works fine.
> I think this one could work well for me with a slight mod. Instead of
> doing a cp from vendor/linux/current to vendor/linux/2.4.21/current, I
> could cp it to vendor/linux/2.4.21/ac, vendor/linux/2.4.21/davem, etc.
> Then track those branches. Does that make sense?
 Yup. If you're planning to maintain more than one co-development tree then,
yes, you need more than what I originally mentioned. You basically need one
"current" style subdir for each tree that you're importing so with vanilla,
ac and davem it'll look like:


plus all of the appropriate snaphot tags (e.g. .../2.4.20/vanilla ; .../ac/1;
.../ac/2; .../davem/1)

> Now, here's the question: how well will this work with svn merge from say,
> 2.4.19ac3 to 2.4.20ac5?

 It depends ;-) I've been doing something similar to what you describe, only
to track separately 2.4 and 2.5 (they are different enough and without a
clean common ancestor that I decided on 2 completely separate import trees
for them.e.g. vendor/linux/2.4/current and vendor/linux/2.5/current). I've
been able to move mods from a 2.4 tree to a 2.5 tree with relative success
(on the few files that were stable from 2.4.20 to 2.5.60...). In my case, the
sheer amount of basic system rewrites made it close to impossible to get a
good amount of portability of the mods.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 8 19:20:24 2003

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.