[Top][All Lists]

[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: Wed, 18 Jul 2001 12:06:21 -0400

Yes, you're right, the line number thing was a dumb idea.  I'm back to saying
that I'm against CVS restricting the checkin of such files, but if CVS were to
do so, then "cvs ci -f" should override this check.


> -----Original Message-----
> From: Noel L Yap [mailto:address@hidden
> Sent: Wednesday, July 18, 2001 7:28 AM
> To: address@hidden
> Subject: Re: Coflict marker detection proposal
> >1. The presence of merge conflict markers in a source file
> managed by a
> >   concurent versioning system is generally an indication that there
> >   were unresolved conflicts in a recent merge.  Since in
> the case were
> >   there was a merge and CVS probably introduced those
> markers itself it
> >   thus has the responsibility to ensure they're removed before it
> >   allows the user to continue and commit the file (clearly
> a file with
> >   unresolved conflicts introduced by the change control
> system cannot
> >   ever be "correct").  Obviously CVS has no way to distinguish
> >   automatically introduced markers from any manually introduced
> >   "real"-looking markers, so the best it can do is require
> that no such
> >   real-looking markers are ever part of the content of any
> (mergable)
> >   source file that it manages in the first place.
> I think it may be possible for CVS to keep track of which
> markers it puts in.
> For example, it can keep the line numbers of these markers
> somewhere in the CVS
> subdirectory.

Umm... this may not be a good idea.  The user may change other things in the
conflicted files which will change the line numbers, so that under this
implementation CVS would "lose" the markers that it had added.  However,
keep in mind that I disagree with Mr. Woods in that I don't think that CVS
should put any restrictions on the content of files stored within CVS.  I
shouldn't have to adjust my source files in order to accomodate the source
control system.

On a side note, has anybody ever heard of a development environment where it
stores its source files in 2-byte Unicode on disk instead of 7-bit ASCII (or
even variable size like UTF-8)?  Wouldn't _that_ just confuse a few
programs?  How about if the first byte of the character is 0x0A?  To most
programs it would probably appear as a binary file.... how would diff3 (and
its relatives) deal with this?  This is still a text file, just not in

Info-cvs mailing list

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]