[Top][All Lists]

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

Re: Coflict marker detection proposal

From: Greg A. Woods
Subject: Re: Coflict marker detection proposal
Date: Mon, 16 Jul 2001 17:39:23 -0400 (EDT)

[ 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.

> 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/ and doc/cvs.texi for examples.  Even src/rcs.h effectively
contains such syntactic sugar too.

> 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.

>  Should CVS now learn all the ways different
> syntaxes of comments?

CVS need not learn anything at all.

>  Should it provide a hook to allow osecification of the
> syntax?

No, absolutely not!

>  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)

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'?

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.

> 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.

> 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.)

>  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)

                                                        Greg A. Woods

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

reply via email to

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