[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: New SHA1 property for nodes returned 'svn ls --xml' invocations.

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Mon, 26 Sep 2016 07:08:37 +0000

Julian Foad wrote on Sun, Sep 25, 2016 at 22:30:54 +0100:
> 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 appreciate that that's your opinion, but I'm going to play devil's
advocate and question it.

The only operation one can do with a content hash is compare it to
another content hash. Our API already has an object with this property:
svn_fs_id_t. The equality relation of node-rev id's is a refinement of
the equality relation of content hashes: equal node-rev id's imply equal
content hashes, but the converse is not true.

What would content hashes provide that comparing node-rev id's would not?


(Node-rev id's( get changed on every text change, property change, or
copy of the node itself, but aren't changed when a parent of the node
gets copied.)
Received on 2016-09-26 09:10:05 CEST

This is an archived mail posted to the Subversion Dev mailing list.