RE: Coflict marker detection proposal

[Kostur, Andre]

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