It's very exciting to hear that Subversion already calculates shas somewhere in
the backend :)
I can't find the cadaver source repo, but a tar.gz for v0.23.3 is on the site.
Unarchiving that, and using ack to find 'sha' (case insensitive) yields no
Can you direct me to any reproducable way of getting a sha out of a subversion
repo for a node, from the client side? I'll just attach Charles to inspect the
wire as I did for svnmucc (that lesser known binary that distributes with svn).
Sent from my iPhone
> On Oct 12, 2016, at 7:16 AM, Bert Huijben <b...@qqmail.nl> wrote:
> This doesn’t look like some kind of update request (more like a commit). We
> use many different propfind requests, which usually only return the requested
> information as that is far more efficient than requesting all properties.
> I don’t see why we would need it on commit, so I’m not surprised that we
> don’t request it from the server just to slow the request down.
> In the implementation I see that we declare the sha1-checksum as live
> properties, so you should be able to request them if you construct an
> appropriate PROPFIND request. The ‘cadaver’ project build on top of the neon
> library might be an easy way to construct such a request.
> From: Paul Hammant [mailto:p...@hammant.org]
> Sent: woensdag 12 oktober 2016 12:55
> To: Subversion Development <firstname.lastname@example.org>
> Subject: Re: New SHA1 property for nodes returned 'svn ls --xml' invocations.
> You're right - and in the fullness of time, I'll replace all the Svn uses
> with their wire equivalents. If Shas were implemented at some future date,
> I'd be happy for them to be available via PROPFIND. I's be even more happy
> for them to be passed back to me in the response of a PUT.
> Or are you saying that shas are presently implemented but I have missed it?
> Cranking up the proxy server, Charles, is a great way to see what Svn is
> doing on the wire. Here is svnmucc pushing up a new resource to Svn (no
> working copy):
> 1. ROOT 401 OPTIONS 0.0.0.0:32768 /svn/testrepo Tue Oct 11 22:58:41 EDT 2016
> 49 1244 Complete
> 2. ROOT 200 OPTIONS 0.0.0.0:32768 /svn/testrepo Tue Oct 11 22:58:43 EDT 2016
> 28 2404 Complete
> 3. ROOT 200 OPTIONS 0.0.0.0:32768 /svn/testrepo Tue Oct 11 22:58:43 EDT 2016
> 14 1470 Complete
> 4. ROOT 200 OPTIONS 0.0.0.0:32768 /svn/testrepo Tue Oct 11 22:58:43 EDT 2016
> 15 2332 Complete
> 5. ROOT/!svn/rvr/64/TestFile 404 PROPFIND 0.0.0.0:32768
> /svn/testrepo/!svn/rvr/64/TestFile Tue Oct 11 22:58:43 EDT 2016 14 858
> 6. ROOT/!svn/rvr/64/TestFile 404 PROPFIND 0.0.0.0:32768
> /svn/testrepo/!svn/rvr/64/TestFile Tue Oct 11 22:58:43 EDT 2016 9 858
> 7. ROOT/!svn/rvr/64 207 PROPFIND 0.0.0.0:32768 /svn/testrepo/!svn/rvr/64 Tue
> Oct 11 22:58:43 EDT 2016 8 857 Complete
> 8. ROOT/!svn/me 201 POST 0.0.0.0:32768 /svn/testrepo/!svn/me Tue Oct 11
> 22:58:43 EDT 2016 179 711 Complete
> 9. ROOT/TestFile 404 HEAD 0.0.0.0:32768 /svn/testrepo/TestFile Tue Oct 11
> 22:58:43 EDT 2016 22 334 Complete
> 10. ROOT/!svn/txr/64-30/TestFile 201 PUT 0.0.0.0:32768
> /svn/testrepo/!svn/txr/64-30/TestFile Tue Oct 11 22:58:43 EDT 2016 86 20391
> 11. ROOT 200 MERGE 0.0.0.0:32768 /svn/testrepo Tue Oct 11 22:58:43 EDT 2016
> 526 1898 Complete
> Doing a second svnmucc operation on the same (now existing) resource, I can
> see via Charles that the second PROPFIND is returning 'rvr/65' for the
> now-existing resource (now a 207 response status). That's certainly not a
> sha, so I think you mistyped.