info-cvs
[Top][All Lists]
Advanced

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

Re: Howto solve this in cvs ?


From: Gerhard Ahuis
Subject: Re: Howto solve this in cvs ?
Date: Mon, 1 Oct 2001 09:12:24 +0000 (UTC)
User-agent: tin/1.4.2-20000205 ("Possession") (UNIX) (Linux/2.2.19-6.2.1 (i486))

Greg A. Woods <address@hidden> wrote:

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

There are not many files, so if you can give me some hints to let a second
vendor branch showup on a normal cvs branch and not on the main, I will be 
very thankfull.

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

No, but it is lot easier for us to find problems if we can easy show the
differences between the different vendor releases and our local changes.
I don't care if this gives some manual admin work to import it all in the 
right way.

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

There are also a lot of files that have minor changes.

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

CVS merges most files without conflicts im my situation. There are only
a few files that require manual intervention.

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

Easy trouble shooting of sources, check which vendor files are in our
released version 2.1 for example. Browsing through cvsweb gives a lot of
information.


Gerhard.

-- 
Gerhard Ahuis
  address@hidden

Unsolicited advertisements subject to $1000 consulting fee.



reply via email to

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