Noel L Yap writes:
>
> I'm running client/server cvs-1.10.8 (with some "cvs edit" patches). The
> command ("cvs up -C file") works fine if noone has yet checked in "file" (after
> the local copy had been checked out). However, it doesn't work in the following
> situation:
> user1 user2
> 1. cvs co module cvs co module
> 2. cd module cd module
> 3. # modify file # modify file
> 4. cvs ci file
> 5. cvs up -C file
>
> Upon step 5, user1 gets:
> (Locally modified loginfo moved to .#file.1.1)
> cvs [server aborted]: cannot open loginfo for copying: No such file or directory
If you use a local repository rather than client/server you get:
retrieving revision 1.1
retrieving revision 1.2
Merging differences between 1.1 and 1.2 into file
rcsmerge: warning: conflicts during merge
cvs update: conflicts found in file
C file
You get similar results if the file has a sticky tag or date and you
update to a different revision.
In my opinion, you should never get merging. If you specify a
particular revision or date, that's the version you should get and it
should be sticky. Otherwise, if there's already a stick tag or date on
the file and you don't specify -A, you should get the sticky revision.
Otherwise, you should get the head version (with no sticky revision). I
don't have a clue as to what -j should do in combination with -C.
-Larry Jones
>From now on, I'm devoting myself to the cultivation of
interpersonal relationships. -- Calvin
