Re: Proposal to fix CVS binary file implementation

[David L. Martin]

From: "Greg A. Woods" <address@hidden>


> [ On Thursday, December 21, 2000 at 00:22:41 (-0600), David L. Martin wrote: ]
> > Subject: Proposal to fix CVS binary file implementation

"Proposal to improve CVS binary file implementation" would probably
have been a better title.  

The larger issue of devising a true "fix" for binary file implementation
is a good topic for discussion, but in retrospect is beyond the scope
of the very specific issue I wanted to raise. Specifically, the functionality
I want to have is to enable project-wide merging (with keywords) using
cvs update -kk -j <TAG> without risk of binary file corruption.

The patch I provided earlier is may be one way to specifically address this by
disallowing override of the -kb keyword expansion mode.  After a week
of testing in my local repository, it appears to work as desired.  If it
never appears in an official CVS release, that's fine.  But it works for me,
and others might find it useful.

> Not until the very end of your message to you hint that you understand
> "merging of binaries" to mean "selecting between alternate revisions".

Consider it a Pulp Fiction post.  (I would have put that in underscores or
in bold, but some people don't have HTML-enabled mail readers).

Having used CVS for 7 years, be assured that I do understand merging.

> 
> >  If the user wants to change the "binary-ness" of a file, this should
> > be performed using cvs admin, but never "on-the-fly" based on options
> > to checkout or update.
> 
> Well, it's not quite that simple.  A file of the same name may have very
> different content on different branches, and if binary files were to be
> supported in some way then it would be necessary to think of the
> situation where a file might be a binary on one branch, but not on
> another, for example.  Indeed a "change" that might be checked in might
> convert the file from binary to non-binary, or vice versa.  I.e. in an
> ideal theoretical world, without constraints, the binariness of a file
> would be defined in the repository on a per-revision basis and could be
> instantly changed by "cvs checkin", which would imply that by default it
> must also be changed in the working directory by "cvs checkout" too.

Because of the implementation of -kb, it currently *is* that simple,
since the binary setting is made in the keyword expansion mode, which
applies to all revisions in the archive.  Whether that's a good thing is a
matter of debate, but it's really outside the scope of the immediate fix
I'm proposing.

> 
> This is obvious.  What's not obvious is how to deal with all of the
> other issues of binary file handling.  Since CVS does not now, and
> cannot by design, properly handle binary files, the tricks of handling
> keyword expansion may as well take precedence over any concept of
> binariness.

I don't think so - not when files can be corrupted as a result of the choice
of precedence.  It's an easy choice for me which should take precedence -
the one which doesn't allow corruption (i.e. don't allow -kb to be overidden).

> >
> >      b) Change the current behavior of update and checkout to never
> >      override the archive-stored default keyword substitution mode for
> >      binary files.
> > 
> 
> I believe you proposal is somewhat naive in that it does not address any
> of the main issues of trying to manage binary files in a revision
> control system that's specifically designed to allow for concurent
> editing.

Naive or not, it fixes a specific problem to my satisfaction.

> Therefore if you do not like the DESIGN of CVS, and by definition the
> constraints it imposes on the resulting product, then DO NOT USE CVS,
> regardless of whatever other features it has which might make it
> attractive to you!

Most software that stands the test of time, as CVS has, must undergo
some amount of extension as it ages if it is to continue to appeal to a
large community of users.  The original CVS design may have been
elegant and succinct, but if it fails to keep up with user requirements,
then the original design has become obsolete.  In that situation, I would
much rather extend, redefine, or even hack the current software if it
results in broader usability and functionality *without* breaking anything.

> 
> 
> Of course if you throw away the silly idea of trying to support binary
> files in CVS with an RCS-format repository, and instead focus on
> extending CVS and the RCS file format definition it uses such that a
> file type can be specified on a per-revision (or at least per-branch)
> basis.  Also devise an extension that allows deltas to be defined with
> byte or (multi-byte) character offsets instead of line offsets.  You can
> then design tools which can do logical difference comparisons of
> variants and merges of changes with specific knowledge of these file
> types.  THEN you'll have a more powerful revision control system that
> can simultaneously handle changes to many file types in an intelligent
> manner.  Such a system could even do intelligent comparisons of
> text-based source files such that changes would be recognized on a
> code-structure level instead of on a text-line level as it is today.
> This is obviously a more intensive redesign, but one which will be
> infinitely more productive than any attempt to handle binary files in
> any way whatsoever.

Tehehehe - it may be silly, but I think the vast majority of users are
in fact using CVS to store binary files as well as text files.  A modicum
of improvement in binary support I think would be well received.

Your infinitely more productive suggestion could take a similarly infinite
amount of time to implement.  I prefer my 15-line patch for now, but if
you have spare cycles to implement your complete fix, go for it!

David