Re: Coflict marker detection proposal

[Noel L Yap]

>[ On Monday, July 16, 2001 at 16:36:49 (-0400), Noel L Yap wrote: ]
>> Subject: Re: Coflict marker detection proposal
>>
>> It is not CVS's jurisdiction to dictate file contents.
>
>It does already.  Get over it.

In what way(s)?  Can they be overidden?

>> Assuming this is the way to go, what format shall this "syntactic sugar"
take?
>
>I depends on the syntax of the content, obviously.  Take a look at
>src/sanity.sh and doc/cvs.texi for examples.  Even src/rcs.h effectively
>contains such syntactic sugar too.

IOW, it's whatever works.  It's not syntactic sugar, but a kludge, after all.

>> They must be ignorable by the language (if it is indeed a language) that'll
>> eventually be parsing this file.
>
>99.999% of the time they are, and there are almost a zillion and one
>external solutions for the other 0.001% of the time.

CVS is much simpler if it did't do any of this.

>>  What about file types that don't have such a syntax?
>
>Have you forgotten so soon already?  (hint: use a filter in the build system)

IOW, kludge your build system as well.

>Have you even searched your system(s) for source files which would need
>to be modified?  Did you find any?  Were any of them files which would
>be checked in without also setting '-kb'?

I have one text file that has these patterns.  No, I don't want to change it.
It needs to stay as is.

>In fact I'll venture out on the limb so far as to say that I seriously
>doubt it's even possible for a non-binary file to ever require any
>detectable conflict markers as part of its normal content.  I.e. it's
>simply impossible that they can't be hidden from CVS' view.

Let's say the sole purpose of the file was to contain these patterns, what then?
Are you now going to dictate that I should never have such a need?

>> Then, as Paul suggested, CVS must provide a way to specify the conflict
marker
>> detection algorithm if it will allow pluggable diff/merge tools.
>
>Don't you think that's something for the person who designs a new
>CVS-like tool with "pluggable diff/merge tool" support to decide?
>
>I.e. it's totally irrelevant at this point.  No such tool exists!
>Arguing about its mythical features is a stupid waste of time.

Keeping CVS more amenable to modular diff/merge tools is only a stupid waste of
time to those who are religiously opposed to such a feature.

>> Your proposal is to block commits when conflict markers are detected (except
>> when there's "syntactic sugar" that denotes otherwise).
>
>No, my proposal is to return CVS to the behaviour it had before Kingdon
>abibtrarily changed it without comment or review, and then to finish the
>uniplemented part of that same feature.   (Well, actually I've already
>done this for myself -- the rest of you should just suffer in silence if
>you don't like what I did.)

So you're going to make a change "without comment or review" as well.  So what
if it's a return to old behaviour?  Two on this list have already commented
against it.  Only one is for it.  I know open source is not democratic, but
neither is it a dictatorstip.

>>  This can very well be
>> done by a commitinfo script.
>
>No, it cannot.  (you're either conveniently ignoring, or completely
>missing, the other half of the problem)

Which other half?
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.