[Top][All Lists]

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

RE: Future CVS Development

From: Thornley, David
Subject: RE: Future CVS Development
Date: Tue, 19 Jun 2001 12:27:49 -0500

> -----Original Message-----
> From: Kostur, Andre [mailto:address@hidden
> > -----Original Message-----
> > From: Noel L Yap [mailto:address@hidden
> > 
> > CVS only requires files to be mergable.  This has a different 
> > meaning from
> > requiring files to be non-binary.
> > 
> > One thing that may be done is to add a hook for pluggable 
> > diffing/merging
> > engines.
As discussed before, this would require at least an extension to the
RCS file format.

The trick is the CVS definition of mergeable, which doesn't just
mean that some sort of diff and patch will produce a file, but
rather that merging two sets of changes is likely to make sense.
That's the usual case with the source code it was originally
designed on, although it's not universal (I remember one case in
which two different changes added elements to a hard-coded array
in different places, and both incremented the array size constant
by one).  If the file format doesn't preserve some sort of locality
(so that a fairly small change affects only one part of a file)
then it has to be treated special.  This is why I'm not hopeful
about Xdelta.  (Another essential part is presenting the merged
file, with conflicts, to the user to resolve, usually by some method
that keeps both changes.)

> Now, pluggable engines would be truly cool!  I know that one 
> large argument
> against CVS here (my office) was that it doesn't do 
> "intelligent" things
> with proprietary format non-mergable files (like MSWord 
> documents), where
> other source control systems can do (the counterexample was always
> Clearcase).  But if you could plug in a diff/patch tool for 
> *.doc files,
> (and perhaps a different diff/patch tool for *.ppt, another 
> for *.xls) that
> would make these files mergable, and thus behave sensibly in CVS! :)
Because of the above, you'd probably need one diff/patch tool for
every file format, and you'd need to keep the diff/patch tools
steadily updated for changes in file formats (MS Word file formats
come to mind as changeable).  This is in contrast to the diff/patch
standard in CVS, which applies to a large number of different sorts
of files, and can remain unchanged.  I'm not sure producing diff/patch
tools for arbitrary file formats is reasonable to expect out of an
open source project.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]