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

[Aaron Bentley]

Szilard Hajba wrote:
> 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.

Are you using a greedy revlib?  You referred to pristines later, and 
pristines are not used when you have a greedy revlib.

Also, baz has a better way of calculating the new-patches header, so it 
doesn't need to scan the entire version to do it.

Also, baz has a cache that will save you from downloading the same data 
twice.

Also, baz doesn't need to scan the entire version when building a revision.

> 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.

baz has improved performance with huge numbers of changesets.

> 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.

Eh?  It should be dead easy to implement.  On the server, run 
"cachedrevs" to see whether the cacherev is present.  If it's not, run 
"cacherev" to cache it.

> > > 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. 

I'm referring to the code you found in archive.h

> But if an archive layer exists, then it have to be implemented on top of the pfs
> layer

One implementation is on top of the pfs layer.  The other implementation 
is the cached archive type used by baz.

> 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.

Yes, that would be exceedingly simple to do.

> > > 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.

I think that only put_cached is necessary for a smart server, because if 
it knows how to construct the cacherev, it can do it when get_cached() 
(or whatever it's called) is invoked.

However, this would be a much better place to add that kind of thing 
than the pfs level.

Aaron
--
Aaron Bentley
Director of Technology
Panometrics, Inc.