X-Spam-Check-By: sourceware.org
Message-ID: <4423B5DC.7010802@cwilson.fastmail.fm>
Date: Fri, 24 Mar 2006 04:03:24 -0500
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Problems with cygwin cvs over ssh.
References: <012820061553 DOT 28125 DOT 43DB937200080D3500006DDD22069984990A050E040D0C079D0A AT comcast DOT net>
In-Reply-To: <012820061553.28125.43DB937200080D3500006DDD22069984990A050E040D0C079D0A@comcast.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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/