Re: cvs up -C bug(s)
Noel L Yap wrote: I don't have a clue as to what -j should do in combination with -C. It seems you've been more thorough than I have. Looking at it another way, "cvs up -C file" should be equivalent to "cvs up -p -r base-rev file file". If other flags (eg "-j") were specified, the command should be equivalent to "cvs up -p -r base-rev file file; cvs up other-flags file". Noel Are you sure about 'base-rev'? From what I've seen so far, -C means 'clean copy'. (it's not on my 1.10.5 copy, gotta upgrade). By 'base-rev', do you mean the revision last checked out, or the current revision for the current sticky tag? Also, how do these two scripts differ? (I'm not cvs-guru enough to know if they do): #1 rm file cvs up all-options file #2 cvs up -p -r base-rev file file cvs up other-flags file // other-flags may be empty And, if it can be done in a script, does it belong in cvs? :-) Michael p.s. Trivia question: What does this do? What should it do? echo 'new file' file cvs add file cvs update -C file (note that script 1 leaves it missing, script 2 leaves it empty) If you think 'just give an error, do nothing', then what if I'm trying to clean up a module, not just a single file?)
Re: cvs up -C bug(s)
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:
user1user2
1. cvs co module cvs co module
2. cd modulecd 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
