[Top][All Lists]

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

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

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] Smart server question
Date: Thu, 21 Apr 2005 10:52:50 -0400
User-agent: Mozilla Thunderbird 0.6 (X11/20040530)

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

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

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

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

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 Bentley
Director of Technology
Panometrics, Inc.

reply via email to

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