Scope of operations

[Robert Collins]

On Sun, 2005-10-23 at 09:43 -0500, John Arbash Meinel wrote:

> That does odd things when you tag a sub-project (say a library) with a
> version. It generally has no meaning about the rest of the files, though
> that may not hurt anything, how do you build a project with version 0.1
> of libfoo, and version 0.1.1 of libbaz? (With arch we just put
> everything into a different branch).

With the NestedTrees proposal, a by reference tree's revision id would
be recorded in my tree's inventory for the tag. No problem :).

> > 
> > But, I know that users often want to work on a small part of their code
> > at once, and it follows that operations like log/revert/commit/annotate
> > (and, if weave shows its potential, perhaps pull and merge), should work
> > on the part of the branch they are working in. Yes, they can commit
> > something that does not work, but they can always just commit the rest
> > too.
> 
> log, revert, and annotate make sense to me. I'm concerned about "bzr
> log" speed, right now it has to parse all of the inventory entries to
> figure out what changed. I realize with weaves, this can be optimized to
> just pull the table of contents. But "bzr log" in a subdirectory means
> having to pull all of the tables for every sub-file.
> Because it would probably be slow, I would rather require it to be
> explicitly given.

So, if its not slow, you're ok with it :). There are a number of ways to
address that, the easiest of which is probably propogating changes up
from children during a commit - but, I think log could easily be full
tree by default without breaking people :).
...
> As far as having pull/merge be per subdirectory....
> I think we can record the pull in the *.weave files, but we have no way
> of recording it in the ancestry. I certainly don't think we would want
> to set a "pending-merges" entry, since a future full tree merge would
> then skip half of the changes, though otherwise it might conflict on the
> other half.

Its really just a partial merge of a subtree - we would record the new
file parents during the merge, and store that explicitly against the
files in the resulting inventory.

> Would you have pull or merge pull all of the changed texts, and
> incorporate their values into the weaves, and then only "merge" the
> changes for the current sub-tree? That is the only way I can see staying
> somewhat consistent, so that a revision entry references all of the
> inventory changes.

I think that that would make sense, though I don't think its necessary.

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051114/7e606628/attachment.pgp