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