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 <ivan_at_visualsvn.com> wrote:
On 24 September 2016 at 15:36, Paul Hammant <paul_at_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
Received on 2016-09-25 02:34:15 CEST