[Top][All Lists]

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

Re: How well does CVS handle other types of data?

From: Greg A. Woods
Subject: Re: How well does CVS handle other types of data?
Date: Sat, 14 Jul 2001 03:10:59 -0400 (EDT)

[ On Friday, July 13, 2001 at 20:19:13 (-0700), Paul Sander wrote: ]
> Subject: Re: How well does CVS handle other types of data?
> I hope your hack doesn't make it into the general distribution.  The
> comment makes total sense.  The authors have no idea if the conflict
> marker results from an artifact of the source code, or from the merge
> program.
> The way people usually "hide" stuff like this is to run an additional
> filter, such as sed, over the source to convert into the real compilable
> source.  This is a horrible kludge, and is way worse than getting a
> conflict warning.

Obviously you're not thinking straight.  All scenerios I can even
imagine, plus all the real ones I know of (including all those mentioned
in the code comment I quoted) allow "hiding" or "escaping" of content
that looks like conflict markers from the CVS checks for such markers
with no added external processing, no loss of functionality, no loss of
accuracy, and no loss of meaning.
It seems you also conveniently ignored the need to internally document
the presence of content that looks like conflict markers such that
future maintainers won't mistake it for what it looks like.

Indeed the act of "escaping" such content from detection by CVS *adds*
information that's important to future maintainers of the file in
question!  (at least for as long as that file is managed by CVS)

(and yes, even if there's no mechanism for escaping special content like
this there's always the ugly filter kludge, but the need for such a hack
will be extremely rare, if ever....  The possibility is so remote I
didn't get so far as to think about the solution until you mentioned it!)

You're beginning, again, to grasp at straws!

> Please, don't modify "cvs update" to skip files with these markers in them.
> Again, they may be a valid artifact of the source.

Paul, we know you don't use CVS regularly any more (or at least that's
what I recall you saying recently -- which begs the question of why you
continue to debate in this forum).  In any case it's obvious from your
comment above that you've either never done enough merging and
concurrent editing to encounter this ultimate mess of multiple
conflicting conflicts; or you've conveniently forgotten about it.  You
should try to quit pontificating and allow other regular users a chance
to relate their real experiences here.

> One other thing, too:  Leaving CVS as it is in this matter makes it easier
> for other users to swap out the RCS merge tool with something better by
> hard-coding in a new program.

WHAT are you talking about?  Have you even looked at the code this part
of CVS?  CVS doesn't use any "RCS merge tool" and it's impossible to
hard-code any other program in there without making drastic changes!

                                                        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]