record_iter_changes and subtrees

[Ian Clatworthy]

John Arbash Meinel wrote:

> Another possibility comes back to having an index of tree-references. In
> which case "commit" then first calls "iter_references()" and pushes a
> "commit" into each of those, which then return with the revision_id they
> want to be, and only after all children have been processed does it
> start commit in the parent tree.

I personally like this design, both from a user expectation and an
implementation perspective. After all, if the user was doing this by
hand, that's precisely what they'd do: commit the subtrees first and
the enclosing tree last.

> Note that the commit in the child trees should be "pending", until the
> top level commit finishes. (A 2-phase commit sort of action.)

It a nice idea but I don't think it's needed in early versions. I also
fully expect that many projects will pull in trees managed in foreign
tools: svn, git and hg in particular. Man, it will so rock using bzr
to pull together stuff using mixed-tool nested trees!

> If *I* was implementing nested trees, I would walk the refs when we find
> them as part of 'iter_changes', though it would require a tweak to tell
> iter_changes that it needs to not just trigger a 'changes' check, but
> also a 'pending-commit' check.

For operations that update the repository (commit, pull, etc.), I'd prefer
seeing the nested trees happening first. For view operations (st, diff,
log), inline would be nice but not a requirement IMO.

My 2c,
Ian C.