Re: how to?

[Jesus Manuel NAVARRO LOPEZ]

Hi, again, Greg:

"Greg A. Woods" wrote:
> 
> 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 where I found my suggestions.

> 
> 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.
> 

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".  But... why!?  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).

> 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".)
> 

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).

> 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.
> 

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.
-- 
SALUD,
Jesús
***
address@hidden
***