You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by John Goerzen <jg...@complete.org> on 2003/04/05 03:19:49 UTC
Maintaining two vendor branches of a single program
Hi,
I've got an interesting case:
I'd like to maintain a development branch of the Linux kernel code for
my own uses. I have set up a vendor branch for it as described in the
Subversion Book. However, I'd like to now base my work on the AC
branch.
For those that don't know, the AC branch is a set of patches on top of
the regular Linux kernel.
Now, my question is, what is the proper way to do this?
I could obviously do something like a svn cp from vendor/linux/current
to vendor/ac/current to start with. And when the AC branch revs, I
can just handle that normally.
But when the Linux branch revs, that's different. The AC patch for a
new Linux version will often be signifcantly different than for the
old one, so running a merge on the AC branch doesn't make any sense.
I thought about just svn rm'ing current on the AC branch and
recreating it, but I think that will mess up merging on a different
branch.
The other thing is that with the Linux branch revs, history on the AC
branch should go back through the Linux branch, so just using a kludge
like building an AC tree out of Subversion and using svn_load_dirs
won't quite do it either.
Any thoughts?
-- John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Maintaining two vendor branches of a single program
Posted by Christian Daudt <cs...@daudt.org>.
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?
>
yes.
> 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:
/vendor/linux/current
/vendor/linux/2.4.20/current
/vendor/linux/2.4.20/ac/current
/vendor/linux/2.4.20/davem/current
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.
cheers,
csd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Maintaining two vendor branches of a single program
Posted by John Goerzen <jg...@complete.org>.
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?
> 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?
> 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?
Now, here's the question: how well will this work with svn merge from say,
2.4.19ac3 to 2.4.20ac5?
-- John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Maintaining two vendor branches of a single program
Posted by Christian Daudt <cs...@daudt.org>.
As long as you check them in in the proper order (i.e. 2.4.20-ac1 before
2.4.20) you shouldn't need the ac/current part. Just check in everything
sequentially to the same import point (vendor/linux/current) and then take
snapshots/tags from there (e.g. vendor/linux/2.4.20,
vendor/linux/2.4.20-ac1).
Given that X.Y.Z-acN is always generated from X.Y.Z and that many times
X.Y.(Z+1) will contain a a bunch of the ac mods you should be fine. Of
course, things that are in X.Y.Z-acN and don't make it into X.Y.(Z+1) will
show up as being reversed back if you diff them but that is how it is
supposed to be. Another option is that you hang the AC releases from the
vanilla release that it applies to.
So method A is:
<cd to linux-2.4.20>
svn import to vendor/linux/current
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]
<cd to linux-2.4.21>
svn import to vendor/linux/current
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.
cheers,
csd
On Friday 04 April 2003 19:19, John Goerzen wrote:
> Hi,
>
> I've got an interesting case:
>
> I'd like to maintain a development branch of the Linux kernel code for
> my own uses. I have set up a vendor branch for it as described in the
> Subversion Book. However, I'd like to now base my work on the AC
> branch.
>
> For those that don't know, the AC branch is a set of patches on top of
> the regular Linux kernel.
>
> Now, my question is, what is the proper way to do this?
>
> I could obviously do something like a svn cp from vendor/linux/current
> to vendor/ac/current to start with. And when the AC branch revs, I
> can just handle that normally.
>
> But when the Linux branch revs, that's different. The AC patch for a
> new Linux version will often be signifcantly different than for the
> old one, so running a merge on the AC branch doesn't make any sense.
> I thought about just svn rm'ing current on the AC branch and
> recreating it, but I think that will mess up merging on a different
> branch.
>
> The other thing is that with the Linux branch revs, history on the AC
> branch should go back through the Linux branch, so just using a kludge
> like building an AC tree out of Subversion and using svn_load_dirs
> won't quite do it either.
>
> Any thoughts?
>
> -- John
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org