RE: Future CVS Development

[Kostur, Andre]

> -----Original Message-----
> From: Thornley, David [mailto:address@hidden
> Sent: Tuesday, June 19, 2001 10:28 AM
> To: CVS-II Discussion Mailing List (E-mail)
> Subject: RE: Future CVS Development
> 
> 
> 
> 
> > -----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.

True, producing the diff/patch tools for arbitrary file formats is likely
well beyond the scope of the CVS project, but other projects may be born to
fill that gap.  However, this can only happen if CVS has the hooks to allow
for alternate diff/patch type tools.