Re: [Gnu-arch-users] Smart server question

[Szilard Hajba]

On Thu, Apr 21, 2005 at 09:03:42AM -0400, Aaron Bentley wrote:
> >But there are some commands that work on the archive, what are extremly 
> >slow.
> >I have made about 20 tags on my imported project. The creation of the first
> >tag held about 5 minutes (!) and transferred several megabytes from the
> >server.
> 
> A tag revision is very cheap-- several k at most.  However, tags from
> another archive also trigger cacherev, by default.  This is to ensure
> that the archive's revisions do not depend on external sources. 
> Auto-cachereving can be disabled, though.
That was not the case. The tags were made from the same archive. That's true
that the tag is itself some k and no cache was generated. Despite this tla
generated several megabytes of network transfer from the server to the client
and it took about 5 minutes to complete.

> >The remaining 19 tags held about 1 second (after I ssh0ed to the
> >server and run the tag commands locally :)
> 
> Assuming they were from the same archive, they would have been fairly
> quick remotely too.
Try it. I simply imported the projekt with 'cscvs totla'. Than it created 1200
changesets. I than made the tag from isdk--mainline--patch-400 to
isdk--releases--2.1.0 in the same remote archive.

> >An other example is cacherev. If I want to make a cached revision on the
> >server it's much faster locally than on a slow network.
> 
> A smart server would only need cacherevs to be performed for the
> tag-from-external-archive case.  If there's a cacherev or import at 
> base-0, no further cachereving should be required, because a smart 
> server can build them on demand.
Yes, but then it needs some intelligence to do it.
It's not a bad thing that I can make cacherevs by hand, because I usually
know, what revisions people will load. Some intelligence would be nice
however, but not as easy to implement.

> >Now the suggestions:
> >
> >As I read the archives I noticed that you had several discussions about 
> >smart
> >servers but as I know there is no usable solutions.
> >
> >1. suggestion: Why don't you make the transport layer pluginable!
> I believe it's better to target the archive layer, not the transport 
> layer.  Operations on the transport (pfs) layer are done in terms of 
> filenames.  Operations on the archive layer are done in terms of 
> revisions, versions, packages and categories.
Yes, you are right, but I couldn't really found an existing archive layer in
tla. But I haven't read all the code yet, so excuse me, if I'm wrong.
But if an archive layer exists, then it have to be implemented on top of the pfs
layer and it would be good if a plugin that defines a new archive access layer
for a smart server could also define an underling pfs layer and use soma
fallbacks of the original archive -> pfs implementation.

> >2. Eztend your abstract filesystem API with optional higher level commands.
> This would mess up the layering in all kinds of ways, and make the 
> simple abstract filesystem API quite complicated.
I have looked into archive.h and I found an arch_archive_vtable structure, but
it has no function to cache a revision. There is the put_cached() function but
that is unusable for a smart server.
So I think the archive layer should be modified a bit to support some
functions.

It's possible that the whole thing is not so important. I am the system admin
of the server I have put the archive on, so I could install tla on it and use
smart server-like features as:
    ssh arch.server.somewhere tla <tla command and args>

But I think it could be better with not too much work :)
I don't think that some optional accelerator functionality in the pfs layer
mess up the layering, but I won't argue :)

$zilu

-- 
Hajba Szilárd                   Symbion Bt.
Tel.:   (+36)20/203-31-56       H-9028 Győr, Új u. 38.
ICQ:    12892911                E-Mail: address@hidden
Skype:  hszilu