Re: how to?

[Greg A. Woods]

[ On Tuesday, September 4, 2001 at 00:40:02 (+0100), Ian Molton wrote: ]
> Subject: Re: how to?
>
> Sorry, but could you slow down a touch?
> 
> whats a 'vendor branched module' ?

A module created by "cvs import", and especially one in which any in-use
revisions of any files remain on the branch created by "cvs import"
(i.e. where the vendor branch remains active).

> surely this is equivalent to me making my own program, branching it, and
> then going back and modifying the 'trunk'?

Nope.  The vendor branch is "magic" in the sense that it supports
conflict detection with subsequent imports, and unless a file is changed
(or forced to move), it says "on" the vendor branch.

Unfortunately the CVS manual has lamely suggested use of "cvs import" to
create new modules for "locally owned" code, even though this is _never_
the optimum way to manage local code.  "cvs import" should only ever be
used for creating vendor-branched modules (though of course the vendor
branch can be cleaned out after the fact).

> (is trunk the right term?).

Yes strictly speaking, though in a vendor branched module it's better
called the "local branch" since the default branch is not the trunk
until a change is committed to a file....

> All I want to do is keep the linux kernel in local CVS so I can make
> branches for the arm patches, and make branches off those branches for my
> own modifications. Is this not possible?

Nope, not without doing a lot of extra manual work.  You cannot safely
or easily mix ordinary branches with the vendor branch.  All kinds of
strange and rarely welcome things will happen (though it might appear to
be working initially).

If you want to learn more about "cvs import" and the vendor branch you
should study the "Tracking third-party sources" chaper in the manual.

There is no really easy way to do what you want with CVS (which is in
some ways why BitKeeper exists).

In fact you should probably try to use BitKeeper for this project if at
all possible, since that's almost exactly what it was designed to do.

With CVS you can limp along but you'd be better off using "cvs add" to
create a virgin module with the kernel source and then creating normal
branches for your patches.

If/when you need to move your patches to a new release of the kernel
then start over with a fresh new module created from the new kernel
sources and then migrate your patches to the new module in the old
fashioned way (eg. with "patch" and/or your text editor).  (Which is why
I'd call it "limping along".)

The only other alternative using CVS is to not create any local "normal"
branches, and instead to just use tags to mark your changes.  This last
is what I do with the *BSD source trees and other larger projects.  This
however makes it VERY hard to separate official patches from private
patches.

-- 
                                                        Greg A. Woods

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