Re: Best Practice To Track Linux Kernel Changes

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