[Top][All Lists]

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

RE: Future CVS Development

From: Noel L Yap
Subject: RE: Future CVS Development
Date: Tue, 19 Jun 2001 15:06:29 -0400

You're missing the point.  I see nothing wrong with CVS handling any sort of
mergable file --  the feature won't break CVS's use on text source files.  If
you think it will, please give a scenario.


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

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]