Re: Xdelta and CVS

[Greg A. Woods]

[ On Thursday, April 19, 2001 at 20:42:51 (+0200), Maarten de Boer wrote: ]
> Subject: Re: Xdelta and CVS
>
> Thank you very much for your answer. It certainly sheds a whole
> different light on things. I will notify the webmaster of the
> mentioned page that the information provided there is misleading,
> and pass your comments, if you don't mind. 

I don't mind at all!

> What I don't get, is why the whole structure of the repository
> would change. Wouldn't it be possible to store the Xdelta output
> instead of the diff output, and in the same place?

The CVS repository structure is defined as being a collection of
RCS-format files.  RCS files use only text-diff deltas.  You can't add
Xdelta files to the CVS repository and still have a CVS repository since
then neither CVS nor RCS would be able to access the complete contents
of repository -- you'd only be able to use some "CVS+Xdelta" program
(and/or RCS+Xdelta program(s)).

> The problem with using PRCS is that it doesn't have network
> support (does it?). From the PRCS webpage:
> 
> "The primary goal of version 2 is to add client/server support
> A snapshot of PRCS2 was released in April 1999 named prcs2-0.18.0.
> Do not try to compile this, it won't do anything"
> 
> That's 2 years ago, so development doesn't seem to be very
> alive. Same goes for Xdelta (latest release Jun. 14, 2000). The
> Xdelta sourceforge pages are even more discouraging. I Cc: this
> mail to it's writer, Josh MacDonald, in the hope to get any 
> information from him. Maybe he has just been to busy with 
> writing PRCS2 to maintain the webpages :-)

I have heard that Josh has been very busy of late.....  How time flies
though....

Of course what is meant by "network support" can simply be a matter of
perspective....  There's no reason why you can't use rsync and similar
programs to script up a set of tools that could efficiently distribute
working directories from some central server.  If your network is fast
enough (i.e. is all a LAN) you could even use NFS or similar to access
the working directories directly on a central server.

In many/most cases there's usually no real need for network support
directly in the version control system.  I only ever use remote CVS
network support to access freeware repositories on the likes of
SourceForge, etc.  (And even then I prefer to have a local mirror copy
of the actual repository and not just remote access to the repo.)

> Another solution might be to use some sort of text format for
> our audiofiles, but I hardly see that feasible...

I'm not sure what that would gain either.....  They'd only get bigger
and the deltas would still be meaningless and unmergable.

Why not just tag the audio files with a version identifier as part of
their name and leave them in a directory outside of any structured
version control system?  You could easily write packaging scripts that
could collect the appropriately named audio files and include them as
part of any released distribution of the rest of your products.  These
scripts could obviously be version controlled with the rest of your
source and so in the end you'd effectively still be using CVS to manage
the versioning of your audio files but just not storing them.   :-)

-- 
                                                        Greg A. Woods

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