Message-ID: <jwv1xe3qkln.fsf-monnier+gmane.comp.version-control.arch.user@gnu.org>
To: gnu-arch-users@gnu.org
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>
	<200412061850.iB6IoWmS036469@xl2.seyza.com>
From: Stefan Monnier <monnier@iro.umontreal.ca>
Date: Mon, 06 Dec 2004 15:00:54 -0500
In-Reply-To: <200412061850.iB6IoWmS036469@xl2.seyza.com> (Thomas Lord's
	message of "Mon, 6 Dec 2004 10:50:32 -0800 (PST)")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Gnu-arch-users] Re: Arch Versus CVS Versus Subversoin
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: 1832
Lines: 43

I think the discussion is misleading.

There are two concepts being discussed:

- the "generic binary diff" where there is no known meaningful diff/merge
  algorithm: the only things the user can hope for is to get back the
  exact BLOB he commited, and that the network/cpu/disk resources be
  used efficiently.  Arch supports those forms of "binary diff" fairly well
  in terms of semantics (you do get back the exact BLOB you committed and
  you can even apply a binary patch as it dosn't have to merge two
  changes).  In terms of resource consumption, it's not great because it
  doesn't try to do things like delta compression.

  I.e. it's about the same as CVS.

- the "file-type specific diff", when you want to do revision control on
  objects where diff/diff3/patch don't work well but where there are
  tools which can do the work of diff/diff3/patch in a meaningful way.
  tla only supports 2 types of objects: text-file (using diff/diff3/patch)
  and directory (where tla itself takes care of merging adds/removes/...).
  It would be useful to be able to plug in more file-type specific
  diff/diff3/patch replacement tools, for things like XML data.
  It could also be used to implement .arch-ids files (instead of directories)
  with their own diff/diff3/patch imlpementation.
  Finally it could be used to plug in your favorite vdelta algorithm
  for those BLOBs where there's no better alternative.

I.e. I don't see the point in improving point 1 since it's only a question
of resource usage, whereas point 2 would both improve the user's experience
and solve ponit 1 as well.


        Stefan


_______________________________________________
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/