Mail Archives: cygwin/2006/03/24/04:03:49
Eric Blake wrote:
> My experience with cvs-1.11.21-1 is that it loses track of conflicts. In
> other words, in cvs-1.11.17, if I do:
>
> $ cvs up
> C foo
> $ cvs up
> C foo
>
> but in cvs-1.11.21, I get:
> $ cvs up
> C foo
> $ cvs up
> M foo
>
> I would much rather see conflicts every time I update, so I haven't
> done much further testing of 1.11.21.
This is apparently not a bug or a regression -- it's a design decision
(misfeature?). It appears that this change is the culprit (not ENTIRELY
sure about that, but I think it's likely):
http://cvs.savannah.nongnu.org/viewcvs/ccvs/src/classify.c?root=cvs&r1=1.25.4.2&r2=1.25.4.3
Here's the comment added to the code as part of this patch (with the
comment *corrected* by this other patch
http://cvs.savannah.nongnu.org/viewcvs/ccvs/src/classify.c?root=cvs&r1=1.36&r2=1.37
on the main 1.12.x branch):
/* Files with conflict markers and new timestamps fall through
* here, but they need to. T_CONFLICT is an error in
* commit_fileproc, whereas T_MODIFIED with conflict markers
* is caught but only warned about. Similarly, update_fileproc
* currently reregisters a file that was conflicted but lost
* its markers.
*/
As best I can figure, what they're trying to say is that if you really
want to, you should be allowed to commit a file that has embedded
conflict markers, but you are not allowed to commit a file that is
classified as T_CONFLICT. So, they ensured that a file with conflict
markers would be classified as T_MODIFIED instead of T_CONFLICT in any
future actions (e.g. you only get T_CONFLICT once).
$ cvs-1.11.17-1.exe -n commit -m testing NEWS
cvs commit: file `NEWS' had a conflict and has not been modified
cvs [commit aborted]: correct above errors first!
$ cvs-1.11.21-1.exe -n commit -m testing NEWS
<no errors>
I also saw something on the cvs mailing list to that effect:
http://lists.gnu.org/archive/html/info-cvs/2005-09/msg00305.html
> Generally, you should resolve conflicts immediately, rather than
> trying to apply another update. By updating without resolving the
> conflicts, you are in effect telling CVS "It's OK, you can ignore
> those conflicts."
I'll try reverting just this change and rebuild to see if I can
replicate 1.11.17's behavior (just out of curiosity) -- but even if it
does, I'm not going to release a 1.11.21-2 with that patch. This isn't
a battle I want to fight: if the upstream maintainers have made a design
decision, I'm not going to second-guess that based on what Eric likes or
dislikes. :-)
FWIW, I've been using cvs-1.11.21 for a while now, so once the next
cygwin dll is released I'll go ahead and promote this version to current.
--
Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -