RE: CVS Update Behaviour

[Paul Sander]

>--- Forwarded mail from address@hidden

>> -----Original Message-----
>> From: address@hidden [mailto:address@hidden
>> 
>> [ On Monday, February 25, 2002 at 00:17:58 (-0800), Paul 
>> Sander wrote: ]
>> > Subject: Re: CVS Update Behaviour

>> huh?  what do vendor branches have to do with this?  If you don't
>> understand that you have to manually move changes between files that
>> have been renamed by the vendor then you should not be 
>> messing with such
>> complicated things that you do not understand.
>> 
>It seems to me that the question is not understanding, but whether it
>is desirable.  It would be nice if CVS would track vendor renames, but
>it would have to be able to figure out vendor renames, and in any case
>the sources we track tend to be kept in CVS anyway, so the supplier is
>unlikely to rename things gratuitously.

I had one that did rename things gratuitously.  Actually, I had two.
One of them changed hyphens to underscores in directory names, the
other performed the following swap:  a/b/c/d --> a/c/b/d

Both of these are conceptually simple changes, and the contents of
of the directories were not themselves renamed and contained
substantially the same bits.  It was rediculous to have to fragment
my version histories for these large trees just for this, but it
was the CVS way and it had to be done.

Sun did the first of these to me in their documentation for the
Solaris operating system.  Sun and USL did the second one to me
with the Solaris and System V kernels.  The workaround we employed
for both of these was to create new modules, but everyone exposed to
these was very unhappy with that solution specifically due to the
fragmented version history as well as the need to keep two sandboxes
and laboriously merge local changes into the vendor drops.  Performing
the merge was very time-consuming, and using "cvs update" instead would
have reduced the effort by about 40%.

>--- End of forwarded message from address@hidden