[MERGE/RFC] Userdoc Driven Design on the Bazaar 2.0 UI
mark at ubuntu.com
Thu Apr 16 07:36:33 BST 2009
Robert Collins wrote:
> On Thu, 2009-04-16 at 00:40 +1000, Ian Clatworthy wrote:
> I do like the docs. However I have some concerns too.
>> 1. checkouts should be lightweight by default (ala svn)
> There are serious performance implications in this. For starters, right
> now this scales with tree size * latency. E.g. its about as slow as its
> possible to be. Is it something we could aim for? Yes, but then we'll
> have to download data over the network for every diff operation.
> lightweight checkouts are really only suitable for high bandwidth low
> latency environments. Fixing them to have a local cache is ~= to using a
> stacked bound branch with sufficient fixes to allow disconnected use. I
> don't think we have the manpower to achieve those fixes in the sort of
> time frame we'd like to have a 2.0 happening in.
Nevertheless, it makes "quick fixes to code that lives elsewhere"
possible. We want a checkout time that is ~= "download the release
tarball". I agree that network-diff is toxic, but am determined that we
get the quick-checkout piece right, and for 2.0.
>> 2. a branch could reuse the repository of a dependent branch
>> without needing to explicitly create a shared repo in a parent
> I think this would make it harder for people to reason about 'where is
> my data' - which is important when deleting branches. If users get it
> wrong they will delete data they care about. Its not /so/ different from
> a lightweight checkout, so perhaps the change isn't that large.
> However, I think the root cause of the issue is that we have an
> expensive resource (the repository) and we want to make more reuse of
> it, but we don't by default make it explicit - so people need to learn
> about it through trial and error, and our toolchain isn't as polished
> for working with one repo, one work area, and multiple branches as it
> should be.
> Misquoting Martin from a couple of days ago, we can either tackle the
> root cause, or we can tackle specific symptoms.
> Tackling the root cause requires effort and though but should lead to a
> better result - consider the brisbane-core project, which tackled
> repository performance issues, and has a really good result - just
> tackling serialisation of inventories, or data compression alone
> wouldn't have gotten the same result [and there are benchmarks from the
> past showing that :)]. It took us focusing down and fixing the actual
> root cause (comparing trees is O(tree) not O(delta)) to get a good
> I think we have to fix the root cause here - our [well intentioned]
> hiding of repositories by default.
> As an expensive resource, repositories are a performance optimisation.
> It is fine (and correct in my opinion) to keep them as just a
> performance optimisation, but we should make them available for reuse by
> Now, as to how we do that, we can look at the suggestion in this story
> of having some sort of pointer to the repository in arbitrary branches
> [but this invalidates some assumptions repositories hold dear, so we
> would not be able to do garbage collection at all anymore]. We already
> violate this for stacked-upon repositories - they cannot be garbage
> collected, *but* we also only stack on branches which means that its
> fairly hard to get references to garbage-collectable-revisions.
> We can have a list of branches in the repository - we currently have
> that by 'ls -lR' under the repository - its the 'branches are contained'
> rule. This is important because it means a repository can reason about
> what data is transient and removable, and what is used. Jelmer's
> colocated branches plugin is a way of extending this without adding
> directories where a user has their source code. There are other ways to
> do this - a list of named heads, or references, can also manage this,
> and would be more efficient at a number of operations (list-branches
> would be _much_ faster).
> And we can stop creating repository+branch at the same place, which
> makes the repository immediately reusable with all of our normal tools.
> In short I think its important we solve the 'reuse the repository' use
> case, but we should aim to do so by reducing the permutations available,
> not increasing them. So some design is needed, including evaluation
> current proposals on the table, and things like the repository design
> Aaron favoured back when we first added shared repositories; then we
> pick one, and run with it.
All sounds fine, and compatible with my suggestions. As you wish on the
internals, but please don't let the UI design drift in the process.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bazaar