FreeBSD Ports statistics
lele at nautilus.homeip.net
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
More information about the bazaar