Re: henrik: memory pool stuff

From: Robert Collins <robertc@dont-contact.us>
Date: Sun, 08 Feb 2004 19:18:50 +1100

On Sun, 2004-02-08 at 13:24, Henrik Nordstrom wrote:
> On Sun, 8 Feb 2004, Robert Collins wrote:
>
> > Longer answer. Tla has to perform a full tree inventory to confirm
> > whether files have been renamed, directories renamed etc.
>
> While this is true, there is not really any need to go beyond
> timestamp+size when determining if a file is modified or not.

This isn't true. If you have two files a & b with the same time & size
(which may happen during a checkout), and you rename a to c, and b to a,
then the content of a has changed, but neither timestamp nor size has
changed. However, we don't read file contents for tagged files (there
are none in the squid sources) IF the inode signature hasn't changed.
(we check various fields - mod time, size, inode - and if none have
changed we use the existing ID from the inode signature cache). For
externally tagged files (.arch-ids/foo.c.id contains the id) we
currently do read stuff, but that will be optimised to not read stuff
beyond a stat() shortly.

> So yes, you need to build an inventory of the tree, but you don't need to
> read and compare each and every file in both the pristine and the working
> tree, just the ones that dos not match the supposed inventory stored in
> your metadata.

Correct. And thats what the latest 1.2 code does. I strongly suspect you
didn't use that latest code...

> I notice the workingdirectory metadata (1.1) is missing signature data
> such as expected modification time and size, but by just adding a little
> signature data to the working directory you can quickly reduce what needs
> to be looked at much in the same manner as CVS does which has been working
> very well for ages. CVS only keeps modification time in the working
> directory metadata for determining if a file is modified or not, but I
> would recommend keeping size as well.

We already do that in both 1.1 and 1.2. Look in {arch}/,,inode-sigs. The
use of that data was not as aggresive in 1.1 as it can be and those
patches are now (IIRC) all in lord@emf.net--2004/tla--devo--1.2.

Cheers,
Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Received on Sun Feb 08 2004 - 04:01:34 MST

This archive was generated by hypermail pre-2.1.9 : Mon Mar 01 2004 - 12:00:04 MST