[RFC] Should we rewrite nested-trees or our formats or punt?

[John Arbash Meinel]

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


...

>> John has proposed instead that WT.iter_changes would always emit tree
>> references, so that we could run commit in the subtrees.  This means
>> that iter_changes is emitting things that it has no reason to believe
>> have changed, and I think it further confuses that API.
> 
> I agree; its very special case and would require all code using
> iter_changes to know explicitly about nested trees. At best thats
> disruptive to our code today.

Actually, I propose more that "iter_changes()" can return entries that
with a "maybe" status. So for files that miss the hash cache, and for
tree-references (since we haven't recursed into them).

Tree-references would then generally be returned by WT.iter_changes()
because we *didn't* evaluate their status.

Note that we don't return unchanged tree-references for
RT.iter_changes(RT) because we know exactly their status.

I believe we already do something along these lines, to prevent "bzr
commit" using iter_changes() from having iter_changes() compute the sha
hash, just to give an object to commit, and have commit then sha it
again to avoid race conditions. (I actually think that we just cheated
on the 'initial commit' case, by never computing or caching a sha hash
for a file that has no parent file.) I still think that something like
iter_changes() which can only say "I don't know" is a reasonable api.
And happens to work smoothly for both maybe-modified files and
maybe-modified tree-references.

Yes, it means that code that uses iter_changes needs to know how to
actually evaluate if the content of the object has genuinely changed.
But commit already does that, and if iter_changes is capable of working
it out, it doesn't seem like it takes a lot of specific knowledge.


> 
>> I suppose you could have a CommitBuilder that was aware of composite
>> trees and managed the process relatively seamlessly, but that's a lot of
>> work and definitely won't be our first cut.
> 
> We definitely don't want to block on having it perfect.
> 
> -Rob

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknMAOAACgkQJdeBCYSNAAM64gCeNgO3GGtIXip0OoGVBIbYzDao
oycAn1DMxPKAvURjLtXUTUvhhVrW9bRI
=mdfA
-----END PGP SIGNATURE-----