I can pull down files from the Svn server (any version) and calc SHA1s on the client side in only a few lines of Python. I'd keep a local database to correlate Svn revision integers.
Can I put the item in Jira and y'all mark it as a 2.0 feature. As with Merkle trees, you'd want it to extend from leaf-most to root-most meaningfully (it should work for directories too) and while that is easy enough, it'd get more complicated if you factor in different read permissions for different directories (and different people). - Paul On Sat, Sep 24, 2016 at 6:06 PM, Ivan Zhakov <i...@visualsvn.com> wrote: On 24 September 2016 at 15:36, Paul Hammant <p...@hammant.org> wrote: > In order to be able to do some Merkle-tree style functions on sets of files > canonically held in Subversion, it would be great to ask Svn for a SHA1 for > the files, or collections thereof from that node downwards. > > I would raise a new feature request direct into Svn, but the JIRA notes says > to not do that, and instead to come here to discuss. > > More info: the technology I'm playing with doesn't do a svn checkout, but > instead monitors the the repo via 'svn ls' (via polling). It is easiest to > hit up the root note and ask for a sha1, then walk the tree (remotely) to > get the actually changes nodes deeper in the tree. Sure, the revision > integer is there too - but I need to compare to a *local* representation of > the same tree that's not under subversion control, and I'll have to > calculate SHA1 of the resource immediately after bringing it down from the > server (rather that just trusting the server's version). > > Of course, I'm focussed on 'svn ls' and I am sure there are other functions > that could report the SHA1 too. > > Someone else might say SHA-2 or 3, and I'm happy to bow to their expertise. > The problem that SHA-1 checksum for files is optional: older repositories/servers may not have this information stored. -- Ivan Zhakov
