You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Lukas Ruf <ru...@rawip.org> on 2004/04/03 15:59:32 UTC
Best Practice To Track Linux Kernel Changes
Dear all,
after I have figured out the basics thanks to this mailing list(!), I
plan importing all my CVS-stuff into subversion. I already fell in
love with the moving feature....
One (next) issue I do not know how to handle with subversion is:
- I am working on several extensions to the Linux kernel of which I
managed the source codes to keep running with latest 2.4 and 2.6 kernels.
- However, I need to stay up-to-date with the kernel core-development,
i.e. whenever a new kernel is released, I must important that kernel
into the repository and apply all the patches.
I have read the svn-book chapter 4 and most "Repository Layout".
Searching the archived has not revealed a hint.
Hence, I would like to ask the mailing list whether there is a
recommendation on how to do what I plan to do.
Thanks for any hint!
wbr,
Lukas
--
Lukas Ruf | Wanna know anything about raw |
<http://www.lpr.ch> | IP? -> <http://www.rawip.org> |
eMail Style Guide: <http://www.rawip.org/style.html>|
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best Practice To Track Linux Kernel Changes
Posted by "Robert P. J. Day" <rp...@mindspring.com>.
On Sun, 4 Apr 2004, Lukas Ruf wrote:
> What I would like to have is:
> - my code resides in the trunk (approx. 20 files)
> - the whole kernel in the repository as a branch to my code
> - whenever a new kernel appears I would like to simply switch the
> kernel code beneath my code.
i'm going to be following this thread carefully as this is *exactly* what
i would like to do.
rday
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best Practice To Track Linux Kernel Changes
Posted by Johannes Segitz <ju...@segitz.de>.
Florian Weimer <fw...@deneb.enyo.de> wrote:
> Occasionally, I merge new upstream releases into the trunk. The
> upstream branch is moved forward in time by applying patch files.
Btw. is there a way to insert patchefiles directly into SVN repository?
Like "svn patch patchfile", preferably an atomic operation regarding to
rejects.
Regards,
Johannes
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best Practice To Track Linux Kernel Changes
Posted by Lukas Ruf <ru...@rawip.org>.
> Florian Weimer <fw...@deneb.enyo.de> [2004-04-04 19:36]:
>
> Lukas Ruf wrote:
>
> > What I would like to have is something like a mapping of a file into
> > another tree. In this case, I would like to work on files in trunk
> > but have them 'mapped' into several other trees. This would imply
> > that all changes I would make to a file found in a branch were
> > immediately reflected in the trunk.
>
> I have worked with such a development environment (with immediate
> updates from trunk to branches, unless the file was copied to the
> branch and modified). It's extremely confusing.
ok, I see. Thanks for the discussion. I think I will follow your
proposal!
wbr,
Lukas
--
Lukas Ruf | Wanna know anything about raw |
<http://www.lpr.ch> | IP? -> <http://www.rawip.org> |
eMail Style Guide: <http://www.rawip.org/style.html>|
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best Practice To Track Linux Kernel Changes
Posted by Florian Weimer <fw...@deneb.enyo.de>.
Lukas Ruf wrote:
> What I would like to have is something like a mapping of a file into
> another tree. In this case, I would like to work on files in trunk
> but have them 'mapped' into several other trees. This would imply
> that all changes I would make to a file found in a branch were
> immediately reflected in the trunk.
I have worked with such a development environment (with immediate
updates from trunk to branches, unless the file was copied to the
branch and modified). It's extremely confusing.
--
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: postino.it, tiscali.co.uk, tiscali.cz, tiscali.it,
voila.fr.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best Practice To Track Linux Kernel Changes
Posted by Lukas Ruf <ru...@rawip.org>.
> Florian Weimer <fw...@deneb.enyo.de> [2004-04-04 18:12]:
>
> Lukas Ruf wrote:
>
> > no. I simply need an "easy" way to port my development to the latest
> > stable kernels.
>
> Ah, okay.
>
> > What I would like to have is:
> > - my code resides in the trunk (approx. 20 files)
> > - the whole kernel in the repository as a branch to my code
> > - whenever a new kernel appears I would like to simply switch the
> > kernel code beneath my code.
> >
> > Does something like this make sense? Or are there better approaches?
>
> I use the following repository layout in this situation:
>
> PROJECT/trunk local tweaks
> PROJECT/branches/upstream latest upstream release (3.0.10)
> PROJECT/tags/upstream/3.0.8 copy of upstream branch at version 3.0.8
> PROJECT/tags/upstream/3.0.9 copy of upstream branch at version 3.0.9
> PROJECT/tags/upstream/3.0.10 copy of upstream branch at version 3.0.10
>
> Occasionally, I merge new upstream releases into the trunk. The
> upstream branch is moved forward in time by applying patch files.
>
What I would like to have is something like a mapping of a file into
another tree. In this case, I would like to work on files in trunk
but have them 'mapped' into several other trees. This would imply
that all changes I would make to a file found in a branch were
immediately reflected in the trunk.
If I re-think my statement, I could follow this procedure by using
some scripting that would traverse the local copy of the trunk and
merge the latest branches into the trunk before creating a new branch
of the upstream.
Does anyone of this list have such a script? Or is there some
standard procedure that subversion provides inherently?
wbr,
Lukas
--
Lukas Ruf | Wanna know anything about raw |
<http://www.lpr.ch> | IP? -> <http://www.rawip.org> |
eMail Style Guide: <http://www.rawip.org/style.html>|
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best Practice To Track Linux Kernel Changes
Posted by Florian Weimer <fw...@deneb.enyo.de>.
Lukas Ruf wrote:
> no. I simply need an "easy" way to port my development to the latest
> stable kernels.
Ah, okay.
> What I would like to have is:
> - my code resides in the trunk (approx. 20 files)
> - the whole kernel in the repository as a branch to my code
> - whenever a new kernel appears I would like to simply switch the
> kernel code beneath my code.
>
> Does something like this make sense? Or are there better approaches?
I use the following repository layout in this situation:
PROJECT/trunk local tweaks
PROJECT/branches/upstream latest upstream release (3.0.10)
PROJECT/tags/upstream/3.0.8 copy of upstream branch at version 3.0.8
PROJECT/tags/upstream/3.0.9 copy of upstream branch at version 3.0.9
PROJECT/tags/upstream/3.0.10 copy of upstream branch at version 3.0.10
Occasionally, I merge new upstream releases into the trunk. The
upstream branch is moved forward in time by applying patch files.
This works reasonably well, but in my case, the project is rather small
(two orders of magnitude smaller than the kernel, or something like
that). One problem with almost all SCM systems is that creating a
branch might be cheap, but continously copying changes from mainline to
the branch (or vice versa) stores all deltas twice: one copy of the
updates to mainline, and one copy of essentially the same changes on the
branch. This is especially true if the branch only changes a tiny
subset of the files.
I haven't run tests, but apparently, Subversion suffers from this
problem, too.
--
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: postino.it, tiscali.co.uk, tiscali.cz, tiscali.it,
voila.fr.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best Practice To Track Linux Kernel Changes
Posted by Lukas Ruf <ru...@rawip.org>.
> Florian Weimer <fw...@deneb.enyo.de> [2004-04-04 11:16]:
>
> Lukas Ruf wrote:
>
> > One (next) issue I do not know how to handle with subversion is:
> > - I am working on several extensions to the Linux kernel of which I
> > managed the source codes to keep running with latest 2.4 and 2.6 kernels.
> > - However, I need to stay up-to-date with the kernel core-development,
> > i.e. whenever a new kernel is released, I must important that kernel
> > into the repository and apply all the patches.
>
> Do you need BK changeset granularity in your Subversion repository?
no. I simply need an "easy" way to port my development to the latest
stable kernels.
What I would like to have is:
- my code resides in the trunk (approx. 20 files)
- the whole kernel in the repository as a branch to my code
- whenever a new kernel appears I would like to simply switch the
kernel code beneath my code.
Does something like this make sense? Or are there better approaches?
Thanks!
wbr,
Lukas
--
Lukas Ruf | Wanna know anything about raw |
<http://www.lpr.ch> | IP? -> <http://www.rawip.org> |
eMail Style Guide: <http://www.rawip.org/style.html>|
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best Practice To Track Linux Kernel Changes
Posted by Florian Weimer <fw...@deneb.enyo.de>.
Lukas Ruf wrote:
> One (next) issue I do not know how to handle with subversion is:
> - I am working on several extensions to the Linux kernel of which I
> managed the source codes to keep running with latest 2.4 and 2.6 kernels.
> - However, I need to stay up-to-date with the kernel core-development,
> i.e. whenever a new kernel is released, I must important that kernel
> into the repository and apply all the patches.
Do you need BK changeset granularity in your Subversion repository?
--
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: postino.it, tiscali.co.uk, tiscali.cz, tiscali.it,
voila.fr.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Best Practice To Track Linux Kernel Changes
Posted by Jeff Bowden <jl...@houseofdistraction.com>.
Lukas Ruf wrote:
>One (next) issue I do not know how to handle with subversion is:
>- I am working on several extensions to the Linux kernel of which I
> managed the source codes to keep running with latest 2.4 and 2.6 kernels.
>- However, I need to stay up-to-date with the kernel core-development,
> i.e. whenever a new kernel is released, I must important that kernel
> into the repository and apply all the patches.
>
>
I've been though something similar to this with subversion so I can
describe how I work it. I use svn_load_dirs. My layout is this:
$SVNURL/trunk/myproj
/branches/myproj/merge-2004-02-28
merge-2004-03-31
...
/vendor/upstream/current
/2004-03-31
/2004-02-28
...
The upstream tree is 'upstream'. 'myproj' is a version of 'upstream'
with local modifications. Let's say the last merge was 2004-03-31 and I
just got a new drop today:
LAST_MERGE=2004-03-31
NEW_DROP=2004-04-04
TRUNK_WC=path/to/wc/trunk/myproj
MERGE_WC=path/to/temp/wc/for/merge
DROP=path/to/new/drop
First I do svn_load_dirs
svn_load_dirs -t $NEW_DROP $SVNURL/vendor/upstream current $DROP
Then I branch
svn cp "$SVNURL/trunk/myproj" "$SVNURL/branches/myproj/merge-$NEW_DROP"
Then I merge
svn co "$SVNURL/branches/myproj/merge-$NEW_DROP" $MERGE_WC
cd $MERGE_WC
svn merge "$SVNURL/vendor/upstream/$LAST_MERGE"
"$SVNURL/vendor/upstream/current"
After I test and fix problems/conflicts I commit changes and merge back
with trunk:
svn commit
cd $TRUNK_WC
svn merge "$SVNURL/trunk/myproj"
"$SVNURL/branches/myproj/merge-$NEW_DROP"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org