Paul Hammant wrote:
Observation: If [a dir had a SHA1] then Subversion would qualify as a *full* Merkle
tree implementation. Albeit through APIs designed for other purposes :-p ;)
There's a bit more to it than just adding a SHA1 for a directory:
* The currently implemented SHA1 of a file doesn't include its
properties, for a start. That's easy to address: add another that does.
* We might want one Merkle tree that includes svn:mergeinfo values
and another that doesn't, so that branches can compare equal even though
the physical storage representation of their mergeinfo differs. That
could be said to be a deficiency of the way mergeinfo is currently
stored, and an alternative solution would be to change that.
* We might also want a Merkle tree excluding all properties, so that
the tree can be compared with a plain unversioned tree.
* How to deal with server authz restrictions. Should a Merkle tree
represent only that part of the tree that the current user is allowed to
see, and/or the "whole" tree regardless of authz restrictions? Perhaps
both kinds are useful.
- Julian
