|
From: | Mark E. Hamilton |
Subject: | Re: Strange CVS behaviour |
Date: | Tue, 28 Mar 2006 13:36:09 -0700 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 |
Thorsten Alteholz wrote:
-> file is moved to .#file.version , but file (which contains the conflict markers >>>>> and <<<<<) is not replaced by clean version from repository So update -C does work unless there was a conflict detected before. This is independent of the client (at least CVS 1.11.1p1 and CVSNT 2.0.5 show this behaviour). Is this a bug or a feature or did I do something wrong? Any help is greatly appreciated.
I've never seen 'cvs update -C' fail, and if it created the backup version then it must have done something (or why would it have created the backup?)
I suspect that what happened is that someone checked in the file with the conflict markers still in it. I'm not sure how this can happen for a real conflict, but I've seen it.
If I add conflict markers to a clean test file manually and then commit it I get this:
% cvs commit blarg1.txtcvs commit: warning: file `blarg1.txt' seems to still contain conflict indicators
but the file is still committed. So, clearly the conflict markers can be checked in.
-- ---------------- Mark E. Hamilton Orion International Technologies, Inc. Sandia National Laboratory, NM. 505-844-7666
[Prev in Thread] | Current Thread | [Next in Thread] |