[Top][All Lists]

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

RE: Future CVS Development

From: Greg A. Woods
Subject: RE: Future CVS Development
Date: Tue, 19 Jun 2001 14:46:09 -0400 (EDT)

[ On Tuesday, June 19, 2001 at 11:59:07 (-0400), Noel L Yap wrote: ]
> Subject: RE: Future CVS Development
> >Of course not.  CVS was not designed to handle unmergeable files.  Ergo
> >your argument is meaningless within its context.  RTFM.
> But CVS+process can handle non-mergable files.

Of course it can!  Just remember though that "CVS does not have a
builtin process model".

> >Most importantly it's not even conceptually possible to a concurrent
> >versioning system on primarily non-mergable files -- the mere concept of
> >allowing concurrent editing assumes theres some way to mostly automate
> >the merging of concurrent changes in a logical manner -- something
> >that's impossible, by definition, for binary files.  RTFM.
> I think you're confusing non-mergable with binary.  For example, if I store
> compressed source in CVS, I can concoptually define an automated merge process
> for these files.

No, I'm explicitly *not* confusing "binary" and "non-mergable".  The
inclusion of the "RTFM" was intended to qualify my statement in the
context of CVS, as it is currently implemented.  What matters to CVS is
"mergability" in the way it has been implemented to do merges, not some
fictional idea of "binariness" (whatever that might be in any given

CVS is not a "concept" -- it's an actual implementation of a set of
concepts and as-is it cannot merge compressed files, regardless of what
form they might take should they be decompressed.  It also cannot merge
any "binary" data structure, even though conceptually it might be
possible to device an algorithm that could merge some specific binary
data structure.

In fact CVS can just barely merge most types of source code and textual
documentation in any meaninful manner.  It can do so only because the
way such content is usually expressed lends itself to reasonably
meaningful comparison with the unix diff and diff3 algorithms (which of
course means that editing scripts can be automatically created which
will apply changes identified by those algorithms to some other file
with similar ancestry).

"Conceptually" what CVS does is to store the deltas of file revisions
and provide mechanisms to copy those deltas to variant revisions.  The
actual implemention relies on how well the unix diff and diff3
algorithms can identify meaningful deltas in changed files.

                                                        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]