info-cvs
[Top][All Lists]
Advanced

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

RE: Conflict marker detection debate


From: Greg A. Woods
Subject: RE: Conflict marker detection debate
Date: Tue, 17 Jul 2001 00:33:34 -0400 (EDT)

[ On Monday, July 16, 2001 at 15:13:23 (-0700), Jimmy Rimmer wrote: ]
> Subject: RE: Conflict marker detection debate
>
> There is also an inherent value in modifying CVS to better support
> unmergeable files.

Fundamentally, no, I don't think so.  There's this "little issue" that
CVS is a _concurrent_ versioning system.  This implies that the content
it manages must generally be mergable.  If you don't believe me just go
look at all the documentation and research surrounding all similar
concurrent versioning systems (even commercial ones like TeamWare and
NSE, for example).

Managing the occasional non-mergable file in a concurrent versioning
system is possible and it may not even cause many major headaches.
However fundamentally it's out of place and must always be treated
specially.

Perhaps some things CVS does now to manage non-mergable files could be
improved, though I see that in a very very different light than what
most people seem to mean when they say the want "better support for
storing unmergable files in CVS".  In fact I see these two things as
being at opposite ends of the spectrum since of course since
fundamentally any concurrent versioning system can only work well if the
content it manages is easily merged by automated tools that can detect
and report likely merge conflicts.  What I would see as improvements are
features and behaviours that would make the unmergability of such files
a focal point so that they stand out more clearly and can therefore be
handled with more care.

The overloading of '-kb' to mean "unmergable" is one aspect where CVS
suffers.  Fundamentally '-kb' should only affect the handling of line
separators and EOF indicators on foreign platforms; while '-ko' should
be used to avoid keyword munging; and some third option should avoid
merging.  I've suggested that this quality of being "unmergable" should
be represented as a special RCS "state".

Merge conflict management for unmergable files is another aspect where
CVS could use improvement.  Paul Sander has presented a recent proposal
that provides for default actions in conflict resolution, which I claim
will only be a source of errors; and I have offered a counter proposal
which will provide a mechanism that forces the user to do a manual merge
(and could offer some convenient helper commands to do the same things
Paul's proposal tries to automate) and would require an explicit
declaration of when the implicit conflict of trying to merge an
unmergable file has been resolved satisfactorily.

In the end though it is only those people who actually want to use CVS
to manage unmergable content who can have any influence over which way
things goe.  Those people can either implement their own solutions, or
they can influence developers (independent or otherwise) with funding
and other incentives to try to get what they want.  Either way the rest
of the community is unlikely to pay any attention to them unless they
can offer up working code to show the success and relative merits of
their particular approach to the problem.  I doubt either Paul or myself
will show up any day soon with working code (I certainly won't unless
I'm first handed promise of some significant monetary incentive! :-).

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