Re: CVS corrupts binary files ...

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Doug Lee <address@hidden> writes:

> Is it a proven thing that CVS can corrupt a binary file if
> no merges are tried and no CR/LF boundary rules are
> broken?

No.

> In other words, if I set -kb on a binary file and then do
> nothing to it but commit updates and sometimes request an
> old revision, keeping my sandbox in the OS in which it was
> checked out, could I ever get a bad result?

I have not ever noticed such a bad result.

I have noticed non-optimal checkout and commit
performance of binary versions of files when the
,v file starts to exceed a few hundred megabytes.

If the server is not properly configured with lots
of memory and temporary space, there can be problems
doing checkouts of lots of files of this type.

> This discussion of binary files has gone on a long time,
> but either I missed the answer to this, or I never saw it
> stated. If Greg Woods is reading this, you implied it once
> in a rather angry message. I welcome the proof, preferably
> without the anger. <smile>

The problem arises when two users concerntly modify a binary
file. After the first user commits, the second is stuck with
trying to figure out how to merge in the other set of changes
by hand with no help.

Advisory locking 'cvs watch' and 'cvs edit' is typically done
for binary files for this reason.

Adrian Constantin <address@hidden> writes:

> > >Adrian Constantin writes:
> > >> 
> > >> Or maybe projects for Unix/Linux platforms
> > >> do not usualy have binary files, but I
> > >> don't really think so...
> > 
> > >CVS is a *source* control system; source
> > >files are rarely binary.
> > 
> > I disagree with this statement. Source files
> > are any files that cannot be reproduced
> > automatically. That is, changes must be made
> > to them manually using some editor, and that
> > editor need not be the likes of vi or emacs.
> > MS Word (or Frame Maker) documents, images of
> > various formats, and documents from various
> > design tools (e.g. GUI builders) are common
> > examples.
> 
>   I tend to see this as a serious break in the
>   cvs design .

Many people do. This is why I and others
consistently suggest that cvs may not be the best
source control system for general use.

>   Today it is not relistic to assume serious
>   projects with many developers involved will
>   only contain text files. 

It is realistic to suggest that cvs is not
optimized for many kinds of 'serious' projects
with constraints of using binary files as a part
of the 'source' to be controlled.

svn, monotone, gnu arch and others have all arisen
more recently than cvs and try in various ways to
address the legacy problems that cvs continues to
have.

>   Also note that diff has the same problem, only
>   for diff it might not be as acute as for cvs.

It is bacically the same problem given that diff
is being used internally to store deltas between
versions.

>   Please note this problem is legacy since the
>   days computer graphics were an advanced
>   technology. When computers were text-based I
>   can understand binary source files were a
>   strange thing in any project.

Possibly. We have always had binary objects, but
many of them have source formats that are
compatible with the older text-based
representations. It is just that most folks choose
not to save the files in those formats for source
control.

>   I would have expected things to evolve.

Things have evolved.

>   I think there are some binary diff algorithms...

Indeed. Consider svn which uses xdelta internally.

To be fair, CvsNt also has ways of dealing better
with binary formats than the cvshome version.
There is a hope that we can move toward merging
the feature sets between those two major varitions
of cvs over time, but it will likely take a bit of
time as no one is being funded full time to work
on just cvs development.

> > >It does support them as an afterthought, but
> > >that's not what it was designed to do.
> > 
> > While this may be true, it turns out that CVS'
> > design can accomodate such files. Support can
> > be added with a relatively small amount of
> > effort, which was demonstrated circa Sept. 18,
> > 2001 in this forum in the form of a patch of
> > the then-current release. All that's needed is
> > a pluggable diff/merge tool based on the type
> > of data.
> > 
>    The design itself does not needs litte
>    changes. cvs
> 
>    design can perfectly acomodate binary
>    sources. It just has to be done (or
>    implemented).

Should I look forward to seeing your patches to
help out on the project? They would be looked at
with favor by all of your fellow cvs users.

>    I think someday I'll use Subversion... when
>    I'll have the time to take it from the
>    begining and start testing and evaluating it
>    as I've done with cvs

Yup, svn is the next likely step for a lot of
folks. It is a good product and getting more and
more features and stability all the time.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAwm153x41pRYZE/gRAjn2AJ4wuAlApuHBuJCRCyTDM2j3bx2l8wCfUNda
2JXTgDtDd3yEijc3AZ2adk0=
=1J/9
-----END PGP SIGNATURE-----