Re: CVS Update Behaviour

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Tuesday, February 26, 2002 at 16:19:11 (-0800), Paul Sander wrote: ]
>> Subject: Re: CVS Update Behaviour
>>
>> >--- Forwarded mail from address@hidden
>> 
>> >[ On Tuesday, February 26, 2002 at 10:27:23 (-0800), Paul Sander wrote: ]
>> >> Subject: Re: CVS Update Behaviour
>> >>
>> >> inclusion, the relationship between the two files becomes variable.
>> >> In the event that a file is moved into a shared module and at a later
>> >> time the target file's history is needed (from within a module other
>> >> than the original one), there's no record of its original module in
>> >> the comment.
>> 
>> >But that is definitely not the general case.
>> 
>> It may not be the absolute most common case (trivial module declarations
>> are), but it falls well within the normal bounds of modules database usage.

>No, not even the "normal bounds" -- only "the possible bounds".

Actually, using trivial modules exposes the problem as well.  Consider
the following three module definitions:

top project
part1-mod project/part1
part2-mod project/part2

Now perform this sequence:

cvs checkout top
cd top/part1
mv some-file ../part2
cvs rm some-file
( cd ../part2 && cvs add some-file )
cd ..
cvs commit -m "moved some-file to ../part2/somefile"
cd ..
cvs release top
cvs checkout part1-mod
cd part1-mod
cvs log some-file

The last thing that appears in some-file's history is
"moved some-file to ../part2/somefile".  This is totally meaningless
because there is no "../part2" directory, and the user has no way to
determine where it is.  This is why the rename feature MUST record the
location of the RCS file, so that the user can find it with something
like "cvs rlog".

>There have been many discussions, and there's even documentation in
>several places, telling all who'll read it that using non-trival modules
>declarations is like dancing with the devil -- you will encounter problems!

Side note:  I can find only one reference to a problem with the modules
database at all in the Cederqvist manual.  And it says to not to rely on
misleading progress messages during checkout of ampersand modules.  There
is no mention of the problems that have been discussed at length in this
forum in the past.

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