Message-ID: <4180E935.50407@panoramicfeedback.com>
Date: Thu, 28 Oct 2004 08:42:29 -0400
From: Aaron Bentley <abentley@panoramicfeedback.com>
User-Agent: Mozilla Thunderbird 0.5 (X11/20040309)
MIME-Version: 1.0
To: Matthieu Moy <Matthieu.Moy@imag.fr>
References: <20041025210724.GA19744@merconline.com>	<200410272144.i9RLiYnd074868@xl2.seyza.com>	<41803AEC.1050209@panoramicfeedback.com>
	<vpqk6tbcnkf.fsf@ecrins.imag.fr>
In-Reply-To: <vpqk6tbcnkf.fsf@ecrins.imag.fr>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: gnu-arch-users@gnu.org, Thomas Lord <lord@emf.net>
Subject: [Gnu-arch-users] Re: Potential flaw in patch-log pruning in proposal
Precedence: list
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 2070
Lines: 51
Matthieu Moy wrote:

> That partly solves the problem for the development of tla, but I think
> other projects need something about patch log pruning, and I don't
> think that's a good idea to force all projects to use the same model.

Other projects need some kind of solution to the problems with the
current patchlog system, but I'm not sure that log pruning is necessary.
    If we're willing to bump the working tree format, there are a few
possibilities that Robert Collins, James Blackwell, David Allouche and I
have been discussing.  Changing the working tree format is, in effect, 
what Dempsky's already doing.

Mbox format
===========
Store the patchlogs for each version together in a single mbox file.
This will reduce space waste (even Reiser has it) and seek problems.
Most of the time, we need sequential access to the patchlogs anyway.

Indices + cache
===============
 From one perspective, having the log contents in the working tree is
just an optimization, and a wasteful one at that.  So get rid of the
patchlogs from the tree, and just store indices of the patchlogs that
would have been present.  To retain the quick access to patchlogs, use a
log cache (or the Arch Cache).  The cache can be optimized to provide
fast access to popular patchlogs, while keeping other logs compressed.

Fix tree access code
====================
Another view is that the current patchlog system is a problem mostly
because of the performance degredation it introduces.  There appear to
still be suboptimal ways we perform inventory.  Fixing those would also
improve large-tree performance.

> I also don't want that because this would mean either to re-implement
> that in Xtla, or use Fai as a back-end for Xtla.

I can understand that.  Does Xtla support Python?  I've pulled out my 
changeset-manipulation code into a separate library.

Aaron


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/