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

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

Re: [Gnu-arch-users] baz format archives in tla


From: Thomas Lord
Subject: Re: [Gnu-arch-users] baz format archives in tla
Date: Wed, 05 Apr 2006 08:17:13 -0700
User-agent: Thunderbird 1.5 (X11/20060313)

Matthieu Moy wrote:
There's another subtle detail that I don't remember exactly about a file which was supposed to be here in tla's archive and which was not actually there.
You are probably thinking about the possibility of creating empty categories and
branches.   The original format supports that.

Regarding speed, the baz archive format _could_ make some operations like browsing faster (you have one directory listing to do instead of a recursive one to do a full browse).
If the product `num_categories * num_branches' for a given archive is large,
and you are performing an operation that wants to look at every version, and
the dominant cost for the archive you are using is i/o latency (e.g., a remote archive over a slow connection or high-latency protocol) and the product `num_categories *
num_branches * num_versions' is not much larger than `num_categories *
num_branches'  then you should see some noteworthy performance gain.

Now suppose that `num_cat * num_branches * num_vsns' is large (compared
to num_cat), you want a list of categories, and i/o bandwidth is a dominant
cost -- then you should see some noteworthy performance loss.

Meanwhile, while people generally don't spend a lot of time navigating archive trees "by hand" there is no reason why they shouldn't. For example, like many people, I use an interactive, outline-style file system browser. With the old format I get a nice interactive archive browser "for free". When archive cached revisions are present, the archive is directly usable as a large-scale distribution site!

And, meanwhile, the loss of the ability to create empty categories and branches still strikes me as a loss. With that capability, an archive administrator can set up categories and branches and say to a project "your stuff goes *here*".
Without them, the admin can not.

And, meanwhile, collapsing the hierarchy as in the baz format makes native
file system access controls less useful. One would like to be able to say that
group A has the right to create branches and versions of category X while
group B has those rights for category Z.   The baz format makes this harder.


-t






reply via email to

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