info-cvs
[Top][All Lists]
Advanced

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

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


From: Rob Helmer
Subject: Re: using files with .xls and .doc in CVS
Date: Thu, 14 Feb 2002 15:59:01 -0800
User-agent: Mutt/1.2.5i

On Thu, Feb 14, 2002 at 04:35:31PM -0500, Eric Siegerman wrote:
> On Thu, Feb 14, 2002 at 10:08:48AM -0800, Rob Helmer wrote:
> > On Tue, Feb 12, 2002 at 09:05:29PM -0600, Pierre Asselin wrote:
> > > Rob Helmer <address@hidden> writes:
> > > 
> > > >Why do so many on the list poo-poo using binaries in CVS? 
> 
> To summarize, there are four issues (at least; if there are more
> that I've forgotten, I'm sure someone will pipe up).  These are
> listed in *my opinion of* decreasing importance:
>   1) CVS's handling of binaries is a bit fragile, in that it's
>      fairly easy to accidentally lose the "-kb" setting.  If that
>      happens, subsequent commits will put garbage revisions into
>      the repo (subsequent updates of older revisions, which were
>      committed correctly, will yield garbage working files, but
>      that's recoverable; the garbage commits aren't).
<snip>



I agree with the rest, but can your describe how the "-kb" setting
can be "lost"?



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

Well, I've found that alot of the time the results of an automatic
merge require manual inspection, YMMV. It's a cool feature though. 

The fact that so many people use spreadsheets and semi-nicely-formatted
documents saved in a non-human-readable is very unfortunate. Hopefully more 
people will transition to various markup languages instead as time goes on.

Even images can be described in XML, which avails itself much more readily
to diff/patch manipulations. Time will tell. The real problem seems to be 
the combination of vendor lock-in in tools that appear integrated to
most end-user/CTO types.

I don't really blame anyone for saying that storing such documents in
a binary format and then versioning that binary format in a system
with deep ties to patch/diff doesn't make sense when there are tools
available to store spreadsheets and other "office" documents in a
human-readable, diffable/patchable format.

This probably is not the best argument for people who wish to store
binaries in CVS, though. In my case, I would *love* to not have .xls
or .doc files in my repository. So far, the farthest I've pushed is
to get people off .xls and onto .xml ( w/ custom schema/stylesheets ).

Right now the .docs are an uphill battle, but a successful migration
of the .xls stuff will certainly help.

Hopefully others won't find this off-topic for the CVS list, but now
I'm curious - is anyone else out there taking these kinds of steps?
Changing the tools of the non-technical computer users is always 
a challenge, but that aside, are many people storing everything in
CVS as human-readable ( XML, SGML, even PostScript ) for not just
developers but "typical office workers" ( define that how you want ;) ?



Thanks,
Rob Helmer
Namodn



reply via email to

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