Re: [Gnu-arch-users] Some issues

[Andrew Suffield]

On Wed, Jun 09, 2004 at 11:51:49PM +0800, Cameron Patrick wrote:
> Andrew Suffield wrote:
> 
> | > The changeset format is defined relative to GNU patch and GNU
> | > tar. These data formats are still somewhat in flux.
> | 
> | What? I'm not aware of anything more stable than these.
> 
> tla requires specific versions of diff and patch to work.  That
> suggests to me that their output format isn't particularly
> well-defined or stable (or perhaps that earlier versions had bugs,
> which amounts to the same thing).

It is though. tla just spots a bug in versions of GNU diff which are
over five years old now (really), and requires a couple of
command-line arguments that not all versions of patch provided. What's
more, that bug was fixed in a backwards-compatible manner. I can't
remember the last time these tools changed in a
non-backwards-compatible manner - ever? It would certainly be a fatal
bug if it happened now.

> | > The changeset format does not handle binaries efficiently, and
> | > certain text files (e.g. XML files not created by a text editor and
> | > formated for readability).
> | 
> | Right, nothing does. Unsolved problem. Nothing to do with
> | tla. Supporting this would be fairly easy if the problem were ever
> | solved.
> 
> We could do better than we do now, though.  Something like rdiff or
> xdelta would be more efficient for some binary files.  We could grok
> gzip/zip/bzip2 files and store some kind of patch based on the
> compressed data.  Having said that, I'm not sure that any of this is
> worth the extra complexity.

And you're just talking compression - that's really not very
interesting. Absent a useful patch equivalent, there's no semantic
difference, so a smarter server or filesystem could do it in the
background without affecting the changeset format.

> | > The archive format optimizes for access to early versions, not most
> | > recent ones as one would expect.
> | 
> | False. The archive format doesn't optimise for anything.
> 
> Yes, of course it does.  I'd say it optimises for simplicity and
> robustness, myself.  Different ways of storing data can affect how
> efficient different access patterns are.  CVS and svn make getting the
> most recent revision O(1) whereas for tla it's O(n).

Not if you have cacherevs or summary deltas. The archive format was
designed to *not* optimise for any of these cases, but rather to leave
it open for tools to select their own optimisations - you can have any
set of performance constraints that are actually possible, depending
on what you put in the archive.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature