This is the mail archive of the
mailing list for the Cygwin project.
Re: Problems with cygwin cvs over ssh.
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: cygwin at cygwin dot com
- Date: Fri, 24 Mar 2006 04:03:24 -0500
- Subject: Re: Problems with cygwin cvs over ssh.
- References: <012820061553.28125.43DB937200080D3500006DDD22069984990A050E040D0C079D0A@comcast.net>
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
$ cvs up
but in cvs-1.11.21, I get:
$ cvs up
$ cvs up
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):
Here's the comment added to the code as part of this patch (with the
comment *corrected* by this other patch
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
I also saw something on the cvs mailing list to that effect:
> 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
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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html