Mail Archives: cygwin/2006/03/24/04:19:32
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/
- Raw text -