[Top][All Lists]

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

Re: Xdelta and CVS

From: Greg A. Woods
Subject: Re: Xdelta and CVS
Date: Thu, 19 Apr 2001 14:22:56 -0400 (EDT)

[ On Thursday, April 19, 2001 at 11:16:31 (+0200), Maarten de Boer wrote: ]
> Subject: Xdelta and CVS
> We are using CVS, for several projects, with great pleasure.
> We now have the need to store and track revisions of large
> binary files (audio analysis data). Because we are already
> familiar with CVS, and use it with clients on various
> platforms, we would like to use CVS for this data as well.

That would be a "not-very-smart" thing to do.  CVS does not in any way
meet your requirements for that kind of data.

You appear to be suffering from the "All I have is a hammer, so every
fastener must be a nail" syndrome, and even though you've begun to
realize that there are these screw-like things in your tool-belt pouch
you haven't yet figured out that you'll create nothing but splinters and
bent screws by trying to bash them into your project.

> Obviously, storing all revisions entirely will not be very
> efficient. The data is pretty straigthforward, and the 
> differences between versions could be extracted very well
> with Xdelta. So Xdelta integration in CVS seems to be the
> solution. 

Sure, but if you do that then you'll be off using an incompatible branch
variant of CVS that has no hope of ever being integrated back into the
main variant of CVS that uses standard RCS files for storage.  Note also
that you cannot change what is considered to be "the main variant of
CVS" unless you convince the majority of CVS users to give up on RCS as
the sole repository file format either.

> The webpage
> looks very optimistic, so I was surprised to find out that
> I could hardly find any other references to Xdelta and CVS,
> let alone a patch or (starting) implementation. 

The first so-called idea on that page is bogus.  It provides no real
benefit in the direction you're hoping to go.  What its author was even
thinking of is unclear.

The second idea is just plain wrong in claiming that it would not change
the CVS repository format since it would, by definition.  RCS uses
"diff" and only "diff" for delta storage.  What it really proposes is to
change RCS.

As for the third idea, well it's less half-baked than its author even
tries to make it sound....

Overall what that web page fails to note is that introduction of such a
drastic change to the repository data structures would make any such
repository incompatible with any normal RCS-only version of CVS, and
indeed incompatible with RCS itself.

BTW, that web page also fails to give full justice to the size of the
project.  If you're really serious about something along these lines
you'd be INFINITELY better off if you simply started a new design for a
versioning tool and wrote it right from scratch.

In any case unless somone creates such an implementation, makes it
freely available, *and* convinces a significant portion of the CVS
community to use it, there's little chance of any success in this
direction.  Of course there are ways to enhance one's chances of success
by also writing lots of tools to help convert repositories in *BOTH*
directions, but there'd still be no guarantees.

Of course you'll get all of my moral support if you do venture out to
design a new versioning tool that meets your requirements!  :-)

> - are there other ways that might be better/easier (like
>   modifying diff)

You could jsut switch to using PRCS, at least for the audio data. It
uses xdelta internally by default already....

> I am well aware of the fact, that CVS has not been designed
> to deal with large binary files, and that some people would
> consider it undesirable to add such functionality. I think
> it is worth the try though. As this is an important issue
> for our project, I can spend some time on this.

You've obviously been blinded by your situation.  What you're proposing
is somthing new and entirely different which may have a command-line
like that of CVS, but which would otherwise not be CVS.  Calling it
"CVS" would be wrong.

                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>

reply via email to

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