Daniel Shahaf wrote:
Paul Hammant wrote:
[...] It is easiest to
hit up the root note and ask for a sha1, [...]
Can you explain more about your use-case? [...]
Hi Paul. I'm +1 on the concept that implementing content hashes in
Subversion would be useful. I think if we were designing Subversion
today, the question would be "Why on earth wouldn't we design in a
Merkle tree content hash?" as it is obviously (to those who have already
thought about it) useful for these sorts of operation, for people
building functionality on top of Subversion.
I think your email subject line misses the point, though, and implies we
already have a content hash defined and available. We don't. The key
thing needed is to design and implement content hashes in Subversion,
rather than about presenting the hash in a specific command.
(Note that any SHA1 hash available in the client-side APIs today is only
of a file's 'text' content, not of the whole node including its
properties, and certainly not of a whole tree.)
So I think a good way forward would be to start a new thread with a
draft proposal for the main feature which is supporting content hashes.
Give at least one real-world example use case, like Daniel asks, so
people can see the point. Then propose exactly how a hash could be
defined on a tree: the property names and values of a node are
represented in form X in the order Y, and the node text is in its
repository form, not 'translated' to WC newline style; and so on. Then
consider any other major issues about the design. One issue I've briefly
discussed before is that repository authorization controls may give a
particular no read access to part of the tree. Then the canonical hash
for the repository's copy of that tree won't match the version of the
tree that that user will see. There are various ways that issue could be
addressed; so propose one.
- Julian
