Re: CVS corrupts binary files ...

[Mark D. Baushke]

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

Adrian Constantin <address@hidden> writes:

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

>   I got it.
>   It will corrupt my files in the default
>   configuration after instalation, until I tell
>   it that .gif files are not text

Correct. The present incarnation of cvs does not
know that a particular file should be treated as a
'binary' just because the file name happens to
match the pattern that some folks use for
Graphical Interchange Format.

I suppose we could collect the cvswrappers provided
as a hint into the contrib directory...

If someone wanted to hack in an automagical
recognition system that could be enabled for
binary file types, I suppose we could consider
adding it.

However, care would need to be taken that files
that happened to be in I8N international character
sets were handled properly too...

> > 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.
> > 
>  
> > >   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.
> 
>   So I see there are many alternatives
>   available, but cvs has not changed. 

No, cvs has changed a great deal. There was a time
when it had significant problems with binary data.
Now, once you tell it that it should treat it as
binary, it mostly does the right thing (as has
been mentioned, it probably should have the
ability to plug in a series of merge programs
other than diff3 to handle binary data better).

It is also true that cvs lacks a full time
advocate for change in this direction.

Most of the advocates of major changes have left
the cvs project to work on a redesign called
subversion.

The current cvs has many problems that are not
yet addressed:

  - renaming files

  - versioning directories

  - dealing with symbolic links

  - better branching models

  - alternatives to diff3 for non-text files or
    structured text files (a la XML and HTML)
    where diff3 does not work well.

  - better access control models

There are a lot of others as well, just look at
the TODO file in the top-of-tree ccvs/TODO file
some time.
    
>   Looks like developers want to offer their new
>   products and not to support the original cvs
>   :( Very sad to find out about this This is so
>   strange and such a bad thing ...

It is not clear to me that incremental improvement
to cvs will necessarily solve some of the major
perceived flaws.

I'd love to see more detailed plans on how to add
improvements to cvs in a controlled way that lets
everyone come along for the ride without lots of
flag days taking place. However, that requires
real work and commitment and a vision of what
problems need to be solved.

> > > > 
> > >    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.
> 
>   Well I write PHP now. I think there's a long way 
>   from web pages to a serious public application

Okay.

>   I hope I'll study xdelta in the near future

It is an interesting topic.

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

iD8DBQFAwrgY3x41pRYZE/gRArvxAJ9GIKVZ+E5SRUSswFlE+tdtnZXsUwCdErq+
C7A9YQeEwaDmJ5AC3wQ+Gwc=
=zrsI
-----END PGP SIGNATURE-----