FreeBSD Ports statistics

Lele Gaifax lele at
Sun Sep 3 12:00:58 BST 2006

John Arbash Meinel wrote:
> Lele Gaifax wrote:
>> John Arbash Meinel wrote:
>>> My best guess is that it parses the rlog contents, and then leaves the
>>> Unicode string in RAM. But doesn't write that to the state file, because
>>> it doesn't need it anymore.
>> Uhm, this clearly shouldn't happen, I'll try to figure out why it's
>> keeping the usage so high.
> Well, as I dig deeper, it might have to do with the state file.
> It seems if you have a state on disk, it only needs to load 1 entry to
> process at a time. Versus having everything loaded. This may not be it,
> but it is definitely something that I saw.

The state file is read an entry at a time, but what you noticed was 
related to the steps *before* state file creation: at bootstrap time, 
tailor needs to slurp the whole "cvs rlog" output and transform that 
into a collection of Changesets that it writes into the state file. From 
that point on, all operations should fetch a changeset at a time from 
the state file.

What it seems happening is that the *original* "cvs rlog" output stays 
around for more than needed... I'll try to understand what's going on.

>> But what do you mean with "it isn't able to combine multiple updates"?
> Technically, all of those have the same revision, and you could instead do:
> cvs update -d -r 1.1 file/one file/two file/three

Yup, this is really simple and effective: I implemented it in

Thank you,
bye, lele.

More information about the bazaar mailing list