Re: Results of egrep -l '^<<<<<<< |^=======$|^>>>>>>> |^\|\|\|\|\|\|\| '

[Greg A. Woods]

[ On Tuesday, July 24, 2001 at 14:27:07 (-0400), Noel L Yap wrote: ]
> Subject: Re: Results of egrep -l '^<<<<<<< |^=======$|^>>>>>>> |^\|\|\|\|\    
> |\|\| '
>
> If you go by popular demand, you're the one thinking backwards here, Greg.
> Since there's no way for CVS to discern  the vendor's
> conflict mark-up from its own, it shouldn't force any conventions on the user.

How backwards your logic is, Noel.  "Popular demand" often (mostly?) has
nothing to do with reality.  You can't change the reality of what CVS is
and how it works (at least not without going to great lengths).  If I
didn't know any better I'd think you're just trying every trick in the
debating book to try and win this idiotic point.

Obviously, just like I've said from the very very very beginning of this
discussion, CVS must not allow unresolved conflicts.  Since it has no
possible way to discern who caused a conflict, and nor can it tell a
real conflict from a faked one either, it must therefore simply refuse
to allow any commit of anything that even resembles the remnants of an
unresolved conflict.  In other words you, the user, must resolve and/or
clear all conflicts or constructs that look like conflicts, before CVS
will permit you to continue a commit operation.

If you can devise a better scheme for marking unresolved conflicts than
is used by diff3 then I invite you to implement it and then to implement
a way to provide it as an alternative merge tool for CVS (perhaps as per
Paul Sander's suggestions).  However until someone does this you're
simply discussing theory and other philosophical issues to the apparent
detriment of your understanding of what's real and working now.

Earlier, before you apparently got on this silly "I must win at all
costs" rampage you more or less agreed with my point, but simply
disagreed on the severity of the issue and insisted that if the commit
is to be dis-allowed then there must be a manual override.  I never
disagreed and in fact I had already proposed as part of my original
sugggestion a per-revision override.  Now you've apparently gone off the
deep end and can't seem to see the entire problem as a whole any more
since you keep picking nits about very minor things and attempting to
twist them into major issues again.

> >Then, secondly, you'd commit your local change.
> 
> And munge two change sets into one.

That's obviously absolutely not the case.  1+1=2, not 1, and never 4.

You can make as many separate changes to any given vendor-branched file
as you wish, and for whatever reasons you wish.

Clearly it's up to you to keep track of why you've made each change and
which are appropriate to feed back to the vendor (if indeed you ever
feed any change back to the vendor -- you don't have to, you know).  How
you do that is up to you.  "CVS does not have change control."  and "CVS
does not have a builtin process model."

> >Obviously a diff from the vendor branch to the local branch will show
> >both changes, but that's for you and the vendor to sort out, not CVS.
> 
> I always thought you supported one change per checkin.

I do, which is why I suggested doing it as two commits instead of one.

How hard are you going to work to try to twist this debate into
something even less meaningful?

You're obviously not even catching hold of the straws you're grasping
for any more.

Please stop repeating your inane pointless arguments.  If you refuse to
accept that CVS is a concurrent versioning system, and all of the
consequences that implies, then please also go somewhere else.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>