[RFC] Strawman replacement local directory state

[Michael Ellerman]

On Tue, 2006-06-13 at 11:45 -0500, John Arbash Meinel wrote:
> Michael Ellerman wrote:
> > On 6/14/06, Robert Collins <robertc at robertcollins.net> wrote:
> >> I've put a strawman working tree state file format up at
> >> http://bazaar-vcs.org/Classes/WorkingTree.
> >>
> >> Its got some interesting aspects, and some things that we might choose
> >> to address...
> >>
> >> Its designed as a 'parse it fully every time, and write it fully too,
> >> but make it fast'. format.
> > 
> > I'm not really across this stuff enough to comment much, you've
> > clearly thought about it a lot more than most people.
> > 
> > Having said that I'm a tad wary of any format involves reading/writing
> > in its entirety.
> > 
> > On the wiki you quote hg, which reads a Dirstate for 19470 files in
> > 220ms. If it scales linearly that'd mean ~23.6 seconds just to read
> > the state for my ~2 million file repository. Am I reading that right?
> > 
> > cheers
> 
> Does anything scale well for a 2 million file repository? I suppose git
> uses a per-directory approach. Though you must have a hell of a lot of
> churn at the top level directory entry. (Since each dir changes when the
> dirs below it change)

That's not the point though. A data structure like this makes it
impossible/hard to speedup partial-tree operations.

If you want to do "status" on 2 million files then it's going to take a
while. I think that's something users accept, because the operation the
user is thinking of "status of 2 million files" is =~ what bzr is doing.

The problem is when a user runs "status just-one-file". They're thinking
"status of 1 file should be fast", but with a data structure like this
bzr is doing a similar amount of work to the full status. I think that
has the potential to annoy people.

cheers

-- 
Michael Ellerman
IBM OzLabs

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060614/8ba22eed/attachment.pgp