Date: Mon, 6 Dec 2004 10:50:32 -0800 (PST)
Message-Id: <200412061850.iB6IoWmS036469@xl2.seyza.com>
From: Thomas Lord <lord@emf.net>
To: stephen@xemacs.org
In-reply-to: <87pt1o9kvb.fsf@tleepslib.sk.tsukuba.ac.jp> (stephen@xemacs.org)
Subject: Re: [Gnu-arch-users] Arch Versus CVS Versus Subversoin
References: <20041205000613.PNEI7152.lakermmtao09.cox.net@nonerjsnum1tkq>
	<26E1F314-4654-11D9-AD55-000A957659CC@spy.net>
	<20041205023828.GA11443@suffields.me.uk>
	<87pt1o9kvb.fsf@tleepslib.sk.tsukuba.ac.jp>
Cc: gnu-arch-users@gnu.org
Precedence: list
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 3162
Lines: 81


    > From: "Stephen J. Turnbull" <stephen@xemacs.org>

    > True, but not a very helpful way to express it.

    > Summary: "binary" files are not readable by humans or programs, so you
    > can't expect their "diffs" to be either.  The only thing a "binary"
    > diff is useful for is exact patching, ie, replacing an exact copy of
    > the "old" file with an exact copy of the "new" file.  Arch implements
    > this by storing a copy of each.  If the old file in the target
    > workspace is identical to the old file in the archive, then it is
    > replaced with the new file by using "cp" (or the equivalent) rather
    > than "patch" or the xdelta equivalent.  Thus, archives are larger than
    > theoretically necessary, but Arch does implement binary diffing and
    > patching as accurately as is possible.

  Another point is that we have seen zero (`0') evidence that any
  significant saving would arrive, under any real-world usage 
  conditions, from the use of binary deltas.

  Suppose that magically, or whatever, all technical issues re merging
  and so forth are resolved.   You can now commit with changes to
  binary files and those parts of those changesets will be
  O(xdelta-result) in size.

  We win a bullet point but....

  Where's the convincing class of scenarios that show me, as project
  maintainer, I should do what I can to raise the priority of 
  binary delta compression?   Note that I am apt to evaluate costs
  in dollars, not (directly) bytes and nanoseconds.

  Who is editting these BLOB files that change in such reliably small
  xdelta increments?   What is it about the xdelta format that ensures
  this (and, hence, how fragile is the situation)?

  I have heard suggestions like "people editting sound files" but,
  supposing that the on-disk format of such files is a compressed one,
  is that really true?

  It seems to me that the relationship of compression to binary files
  reveals the implausibility that binary delta compression will be 
  significantly useful:

  Programmers often use binary files for space compression.  Many
  forms of compression share the familiar chaotic property of formats
  like `gzip': small changes to the "content" that generates the
  compressed form generated global changes to the compressed form.

  [[cartouche!

    The better a job binary-file-format designers do at space
    compression -- i.e., the more reason there is to have most
    binary file formats *at all* -- /the less useful it is to 
    have generic binary delta compression in a revision control
    systems!/

  ]]

  Don't get me wrong: I can think of plenty of applications for
  non-textual diffs.   I just don't see any huge wins for generic
  binary diffs.  Does anyone else?

  I hate it when people ask for features that don't make sense
  but then it takes 3 years to figure out how to articulate why
  the original request doesn't make sense.   Don't you?


-t


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/