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

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

Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implement


From: Colin Walters
Subject: Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes
Date: Fri, 30 Jan 2004 20:42:50 -0500

On Fri, 2004-01-30 at 20:08, Tom Lord wrote:

>       DELTA $archive * $revision
> 
> invariably returns the changeset that is stored for $revision.  It
> should only ever fail if $revision is an import revision.  You should
> never need access to the tagged revision to compute

Right, OK.

> Music to my ears.   Stick an optional server-side revlib in there,
> too.

How would a server-side revlib work?  I thought most of the efficiency
of a revlib came from the hard-linking.  There isn't a way to send those
over the wire :)

> For that matter, (later, of course) we could extend the protocol to
> permit:
> 
>       DELTA $archive1/$revision1 $archive2/$revision2
> 
> and think about cases where a single server or local fs is hosting
> multiple archives.   We want to avoid _too_ much non-determinism that
> would have arch commands searching all over the world for a server
> that can optimize some case but I'll bet we can do something nifty
> along these lines.

Yeah.  I think it should be possible if archive1 and archive2 are both
managed by the server.  

A client could actually know to do this if the locations for both
archives mapped to the same arch server.

> rel_table arch_archive_patch_log_listing (arch, revision)
> 
> is the big one, I think.
> 
> Could maybe be generalized to:
> 
> rel_table arch_archive_headers (arch, ancestor_revision, revision)

But there, you have to know the revisions in advance.  What if I wanted
to specify things by date, as in my above example?

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


reply via email to

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