info-cvs
[Top][All Lists]
Advanced

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

Re: CVS corrupts binary files ...


From: Doug Lee
Subject: Re: CVS corrupts binary files ...
Date: Sat, 5 Jun 2004 20:24:09 -0400
User-agent: Mutt/1.5.4i

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

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>

On Sat, Jun 05, 2004 at 05:10:58PM -0700, Paul Sander wrote:
> >--- Forwarded mail from address@hidden
> 
> >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.
> 
> >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.
> 
> And before someone rehashes the old "you can't replace diff without
> breaking RCS" argument, remember that I'm not recommending replacing
> the algorithm that computes the deltas.  This is strictly a UI thing
> in the top layer that is well outside the back-end design.
> 
> >--- End of forwarded message from address@hidden
> 
> 
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/info-cvs

-- 
Doug Lee           address@hidden        http://www.dlee.org
Bartimaeus Group   address@hidden   http://www.bartsite.com
"It is not the mountain in the distance which makes you want to stop
walking; but the grain of sand in your shoe."  --Anon




reply via email to

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