This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problems with cygwin cvs over ssh.


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]