[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how to?

From: Greg A. Woods
Subject: Re: how to?
Date: Tue, 4 Sep 2001 14:32:19 -0400 (EDT)

[ On Tuesday, September 4, 2001 at 13:31:49 (+0200), Jesus Manuel NAVARRO LOPEZ 
wrote: ]
> Subject: Re: how to?
> There is where I found my suggestions.

Yes, the manual is very good at misleading people -- almost better than
it is at informing them sometimes!  :-)

> OK, I think I see now, though I still don't understand...
> So, the way you propose is "have the stock kernel as the main branch,
> and do your work on "lateral" branches".

Not necessarily.  You might create a branch for the stock kernel and
check in new revisions there.  You might not even ever use the trunk,
but rather always only work on branches.  Keeping the stock kernel on
the trunk is the logical thing to do, but then you'd have to be quite
careful to not ever check out the trunk and work on it locally, and
since that's the default action of CVS, it's a likely error that could
be made.

>  But... why!?

Because you cannot safely use regular branches in a vendor-branched module.

It will not work for anything complex (eg. a kernel source tree!).

>  I can see much
> better that stock kernel should stay as a vendor branch while Ian does
> his work on the main branch (where he can safely make as many branches
> as he wants -well, as safely as CVS supports branches).

CVS does not support branches from vendor-branched modules.  In the way
it is implemented it simply cannot.

(you might be able to get away with doing a "cvs admin -b1" after every
import, i.e. to basically turn off the CVS vendor branch support, but
that wouldn't really make anything very much easier for you, and such an
operation is itself prone to race conditions if you've other developers
working on the same module simultaneously)

> > If/when you need to move your patches to a new release of the kernel
> Odd. What I see is the other way around (and it seems to me much
> easier).  You don't patch the stock kernel with your changes, but patch
> your modified kernel with stock kernels updates (coming from the vendor
> branch).

Yes, you'd still be doing that, but all manually (no "cvs import").

If you want to use CVS to both track the "third-party" (i.e. the
original stock) kernel sources and to use it to assist you with merging
changes in those releases to your local branches, while of course at the
same time having the ability to work on several normal branches, then
you have to manually create your own local branch onto which you commit
the third party source releases, and you have to manually merge changes
from that branch to your other working branches.

What you'd end up doing is committing new kernel releases to the stock
kernel branch, and the merging those changes from that manually
maintained "stock kernel" branch over to your local branches.

Note that "branches off of branches" wouldn't work very well here
because it would require re-creating every one of them with every

> True.  Still I don't see why the method I'm taking about (well, at least
> I *thought* that was the method explained at the "following third party
> sources" doc) has any problem.

The CVS vendor branch support was really just meant for the simple case
-- where there's a third party supplying releases of code, and locally
you want to be able to make changes to that code and then propagate your
changes to the next vendor release.

Even for that simple task CVS can sometiems fail spectacularly.  The
regular appearance and disappearance of files in a vendor branched
module can cause major merge nightmares even if there have been no local
changes.  For expample in the *BSD ports/pkgsrc systems where patch
files might come and go periodically, a vendor branched module will
require local manual conflict resolution for every case where a patch
file of the same name has been deleted and then re-added by the vendor.
This is a nightmare once you've done a dozen or so merges over a six
months period and have hundreds of such files to "merge".  I now track
NetBSD pkgsrc by simply checking it out from the official repository
(well a local mirror of it) and then never committing my changes -- cvs
update does the merges for me.  The drawback is of course that I can
never tag a local release, nor even create commit messages to remind
myself of why I've made local changes.

I have dreampt up ways to fix this problem, but I haven't tried to
implement them yet, and if I did I'd probably build a system around SCCS
given its superior reliability and given that there's now a couple of
variants of free implementations (some even close to production quality).

That's OK though -- the original promise of CVS support for tracking
third party sources was never really fulfilled anyway.  While the
conflict detection works in the general case it doesn't save any time or
effort.  If I were to find the time to implement my "cvs add" proposal
then "cvs import" and the vendor branch support could basically be
ripped out of CVS and forgotten as a failed experiment (well there's the
problem of supporting guys like myself with several gigabytes of
old-style vendor branched modules of course... :-).

                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]