Re: using files with .xls and .doc in CVS

[Paul Sander]

>--- Forwarded mail from address@hidden

>>   2) CVS can't automatically merge changes.  This matters more or
>>      less depending on (a) how frequently the files change (hence
>>      the gif vs. spreadsheet discussion), and (b) how hard it is
>>      to merge changes manually, or through semiautomatic tools
>>      external to CVS.
>> 
>This can be a bit of a problem. Using watches and cvs edit makes things 
>bearable in this respect.

CVS can be made to merge changes to binary files.  Search the archives
of this mailing list for message ID address@hidden
for one method to make CVS' merge mechanism extensible.

>> 
>>   4) As you noted, deltas for binary files tend to grow more
>>      quickly than those for text files, since the former don't
>>      "diff" as well; thus, the ,v files get bigger, faster.
>>      Personally, I don't really care; disk is cheap.  But others
>>      have different circumstances.
>> 
>There is one other thing to consider about this. To do operations on the ,v 
>files CVS reads them into memory. As the file gets larger so does the demand 
>on your CVS server. As long as you don't have really large files that change
>a lot you should be okay with this for a while.

The definitive RCS sources permit configurations that can either memory map
files or use temporary files, depending on the capabilities of the system.
Although CVS' "librified" RCS cuts corners to get the basic capabilities,
it does little more than expose the command line as an API.  It should be
(theoretically) possible to pull in the definitive RCS sources into CVS
and regain that capability.

>--- End of forwarded message from address@hidden