On Mar 24 04:03, Charles Wilson wrote: > 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. > [...] > 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. :-)
I know this is off-topic for this list, but 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. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/