info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coflict marker detection proposal


From: Noel L Yap
Subject: Re: Coflict marker detection proposal
Date: Mon, 16 Jul 2001 16:36:49 -0400

>[ On Monday, July 16, 2001 at 10:23:03 (-0400), Noel L Yap wrote: ]
>> Subject: Re: Coflict marker detection proposal (Was: How well does CVS
handle other types of data?)
>>
>> OK, so let's discuss it now.
>>
>> If conflict marker detection were introduced, it would do one of a few
things:
>
>"RE-introduced"  (actually it's already there -- it just has to be
>*RETURNED* to being an error.
>
>> 1. prevent checkin of files that legitimately had a conflict marker.
>
>Absolutely!
>
> 2. force kludges in such files just to be able to check them in.
>
>"kludge" is a nasty word.  "Syntactic sugar" is much closer to being
>both correct and connotatively ideal.  Show me files that need syntactic
>sugar first though....  (Even "sanity.sh" gets by quite well because it
>normally has to hide most such patterns from its own RE parsing.)

It is not CVS's jurisdiction to dictate file contents.

Assuming this is the way to go, what format shall this "syntactic sugar" take?
They must be ignorable by the language (if it is indeed a language) that'll
eventually be parsing this file.  Should CVS now learn all the ways different
syntaxes of comments?  Should it provide a hook to allow osecification of the
syntax?  What about file types that don't have such a syntax?

>
>Of course if '-kb' is going to inhibit use of the diff3 algorithm then
>it may as well inhibit subsequent conflict marker detection too....
>
>> It would also needlessly further tie in diff3 into CVS greatly inhibiting any
>> pluggable diff/merge solution in the future.
>
>Huh?  Now you're not thinking clearly either.

Then, as Paul suggested, CVS must provide a way to specify the conflict marker
detection algorithm if it will allow pluggable diff/merge tools.

>> OTOH, if developers wanted something like this, they can use a commitinfo
script
>> now.
>
>That's not sufficient.

Why not?  (Why must I even ask this question?  Isn't it obvious that the answer
isn't obvious to me?  Is it your way to buy a little more time to dig up an
answer?)

Your proposal is to block commits when conflict markers are detected (except
when there's "syntactic sugar" that denotes otherwise).  This can very well be
done by a commitinfo script.

Noel



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]