record_iter_changes and subtrees

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Bentley wrote:
> Robert Collins wrote:
>> So, iter_changes and subtrees.
> 
>> currently recursive='down'
> 
> recursive='down' in what context?
> 
> Aaron
> 

Robert is trying to get "bzr commit" to work when you have subtrees
enabled. I believe the internal "commit.py" code uses "recursive='down'"
to indicate that while you are committing the top-level tree, you also
want to commit all of the child trees.

And the problem Robert is having is that 'iter_changes()' isn't being
recursive, or at least not helpfully so.

As I see it the commit code itself needs to be recursive. So when you do
commit at the top level, it starts scanning directories for changes. If
it finds a tree-reference, it then needs to "recurse" and start a
'commit' in that tree. Then the sub-tree can decide whether it has
changed or not, if it has, it needs to commit and generate a new
revision_id, so that the parent tree can see the new revision_id, and
see that it needs to record a new inventory entry for the subtree.

I think the current layering issue is that it is 'iter_changes' which is
walking the directories, and it doesn't know that a 'commit' is going
on, in order to say anything to the 'tree-reference' it finds.

I believe Aaron's original plan was that 'bzr commit' in a tree with
subtrees would use a completely different "Tree" object (some sort of
combined tree).

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.

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

Anyway, if we did the 'commit(iter_references())' before commit in the
top-level tree starts, then it should be able to notice that the
revision_id of the child trees has been updated.


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.

Or alternatively, just a flag to iter_changes that tells it to always
return 'tree-reference' (treating them as always modified until further
inspection.)

That may not even need a flag. Consider the "bzr diff" case. We want to
recurse into the child directories, because we don't know whether
anything has changed there or not (yet).

Again, I believe the current design is to recurse either before- or
after-the-fact (using iter_references), but it seems nicer to have it
done *during* another operation.

John
=:->


> 
>  when there is a change in the subtree fails
>> spectacularly because iter_changes doesn't examine the subtree and
>> decides that the tree reference is unaltered.
> 
>> For now, to get things ready to land I'm disabling using
>> record_iter_changes when the repo supports subtreess which unfortunately
>> needs to be reenabled on chk subtree repositories.
> 
>> I'm not sure what the best answer is - should iter_changes take a
>> recursive parameter?, recurse automatically? something else. Perhaps
>> recursive is too generic (does it mean per-dir, or subtrees or what).
> 
>> -Rob
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknKPN0ACgkQJdeBCYSNAAPrbQCgpTYm97Zc3d9FxWX5Iyl7i9ay
xzUAniySP7U7U2FNZhqIsmGSWt3nJZ9K
=Pye2
-----END PGP SIGNATURE-----