cvs-1.11.21 and behavior on 'Conflict'

[Charles Wilson]

Hi - I maintain the cygwin (http://www.cygwin.com/) package of cvs and 
currently we distribute 1.11.17, and I have a 1.11.21 version in 'beta'. 
 I'd like to promote 1.11.21 ... and then perhaps release a beta of 
1.12.x.  However, my users have reported some problems with 1.11.21:

> 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.

As far as I can tell, this new behavior was introduced here:

http://lists.gnu.org/archive/html/cvs-cvs/2005-09/msg00899.html

(1.11 branch, but later merged to 1.12).  *IF* I am correct, reverting 
to the previous behavior is not as simple as just backing out this 
patch, because the patch appears correct a number of other misbehaviors 
AND changes the internal interpretation of T_CONFLICT (e.g we can now 
"trust T_CONFLICT" -- as if it wasn't trustworthy before?  Which flies 
in the face of the testcase above, where there exists a conflict but it 
is not being reported the second time!)

So, I have two questions: is the behavior in the test case above 
intentional, and if so, what is the reasoning behind the new behavior? 
If a conflict is reported on first cvs update, and I *do nothing*, 
shouldn't cvs continue to report that conflict until it is fixed?  Where 
am I going wrong?  Another of my users wrote, in response to the above 
report,

> I consider this change as
> rather frustrating, too.  I'm often in the situation that I have to
> update a CVS tree which has lots and lots of changes.  A single `cvs up'
> floods the terminal window with output, so I call `cvs up' again, to see
> only the relevant information (C's and M's).  However, with this change
> you lose the information that an M is actually a C.  This is very
> user-unfriendly.

So, if this is NOT the intended behavior ... can it be corrected? <g>

--
Chuck