gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] arch lkml


From: Robert Collins
Subject: Re: [Gnu-arch-users] arch lkml
Date: Sat, 13 Dec 2003 19:44:38 +1100

On Sat, 2003-12-13 at 19:26, Eric W. Biederman wrote:
> As far as I can tell because of the current structure of arch
> repositories I cannot have two copies of the same repository on two
> separate machines because then there would be no way to prevent a
> collision when two simultaneous revisions of the same base version
> are checked into the different archives.

You can't have more than one writeable location at a time, for any given
archive name. Thats a prime ACID requirement. If you want that... then
have two archives, and merge between them.

> The problem is once an archive system is a fundamental part of your
> process it becomes very hard to change.  
> 
> The best practical test I can think of for having semantics that are a
> superset of other systems is if you can import and reexport other
> archives without loss of information.  One of the things unicode got
> right.  Of course once you have done sophisticated things you may no
> longer be able to reexport into a lesser format without data loss, but
> that does not apply into the import/export case.

We can do that.

> The open questions I have are for making my decision are:
> 
> 1) Is there truly a benefit to the binary data structures used by
>    xdelta, svn, and talked about in several academic papers.

xdelta is orthogonal to the changeset format used by arch. If, for
instance, binary files become a limiting factor, we can use a
binary-diff such as xdelta for that component of the changeset. So
whether there is or isn't a benefit ... if there is, we may choose to
leverage it, without design problems.

> 2) Are the semantics of arch rich enough to keep it from running
>    into a wall I care about in the future?

I believe so.

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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