Re: Howto solve this in cvs ?

[Greg A. Woods]

[ On Saturday, September 29, 2001 at 23:40:46 (+0000), Gerhard Ahuis wrote: ]
> Subject: Re: Howto solve this in cvs ?
>
> What is not working well ? I didn't have any problem until this problem 
> arrises.

Does it really matter when the problem raises its ugly head?

Don't try to use normal branches with vendor branched modules unless you
want to invite trouble!  (This is unrelated to the following issue too!)

It's really not that hard to figure out where the problems arise if you
look in detail at how CVS creates branches and how "cvs import" works.

For many of the same reasons it's literally impossible to ever have true
multi-vendor support too -- all the benefits of "cvs import" are
completely impossible to achieve with multiple vendor branches.  You can
do multi-vendor tracking manually, but it's one hell of a lot more work
(more work even than managing several variant branches in a locally
initiated project)!


> > Your best approach is to start fresh with the 3.x release in a new module.
> 
> That is not the way a version control system should work I think.

Huh?

What do you expect?  Black magic?  Miracles?

This is CVS we're talking about and while there is some undocumented
magic in it, it sure as heck can't pull off miracles for you.  The
vendor branch support is a simple hack that only really works well in
the simplest of cases.

When a vendor drastically re-arranges code and files in a new release it
is _always_ better to start a new module and to manually carry over ones
changes from any old module (if indeed they are still appropriate and
necessary).  This is probably even documented somewhere (but I'm too
lazy to search for you).

It's irrelevant whether or not you think this is how a version control
system should work -- it _is_ the way CVS works (or doesn't, as the case
may be).

The way CVS handles file hierarchy changes and renames requires
out-of-band information about the programmer's intent be recorded in the
commit logs to facilitate subsequent understanding of the change.  It is
impossible for CVS to guess what this information is in a "cvs import",
and it's unlikely that even a human could get it right without going to
a great deal of trouble (and if you're going to go to that amount of
trouble then you should simply avoid "cvs import" entirely and manage
your repository as is you were the vendor, not the consumer).


Perhaps you should try to think about _why_ you are tracking local
changes to some vendor code and try to figure out what benefit you gain
from using CVS to assist you with this task.  Contrast all of this with
the more traditional way of managing local changes by creating local
patch sets and applying them to new releases, and with schemes which
automate this kind of patching, such as the *bsd "ports" or "pkgsrc"
systems.

-- 
                                                        Greg A. Woods

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