scaling of shared storage

Jan Hudec bulb at ucw.cz
Mon Feb 6 15:57:43 GMT 2006


On Mon, Feb 06, 2006 at 10:21:12 -0500, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> John A Meinel wrote:
> > I think the best mention was to split up the inventory so that you had
> > each directory having just its inventory, and then the base inventory
> > becomes the tree root id.
> 
> I'm not sure about this; it seems like a half-measure.  There's nothing
> preventing bad scaling behaviour *within a project* this way.  So I
> think we may want to split inventories further, perhaps every 100
> revisions, or every x bytes, or something.

The question is whether /that/ actually helps anything. That is how much
it helps after knits are in. On the other hand splitting inventory
per-directory certainly does help anything (most projects contain
directories they touch rarely) and it would make branching a subtree
some bits simpler. Which I think would be an important feature - you may
often realize you want to split out some part as library only after a
while when it grows to substantial size.

> > We need tree root ids to properly support nested branches anyway (both
> > by-value and by-reference work better with a root id).
> > 
> > Right now, you could find it because you have other meta-information
> > (you have the working inventory). But you are completely correct. Each
> > revision would need to add a 'tree-root-id' parameter, so that we can
> > look up in remote.
> 
> I think in previous emails, we got as far as the idea of calling the
> tree-root-id the 'project-id', and using it for other things.  It might
> be useful to the launchpad folks, for example.  Anyhow, I'm pro ids for
> tree roots.
> 
> But last time, we were setting a tree-root-id for the NULL revision, and
> I think that was wrong, because the NULL revision should be the same, no
> matter what project you're talking about.
> 
> This implies that the tree root is added in the first revision, and that
> is okay with me.  I will happily make whatever changes are needed to
> avoid actually creating / deleting the root directory.  (Though the way
> branch creation works, I don't think we need to do that.  Probably we
> just need to make it illegal to revert to -r 0)

Maybe not even that. When you add a file, all it's parent directories
need to get added automatically -- which includes root. revert -r 0
deletes the root... you get a new project when you add it again, but
I think that's OK -- while the operation is legal, it's hardly sensible.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060206/eaf2122a/attachment.pgp 


More information about the bazaar mailing list