Problems with cygwin cvs over ssh.

[Charles Wilson]

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/