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 matches. 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). Regards, - Paul 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. > > Bert > > > > From: Paul Hammant [mailto:p...@hammant.org] > Sent: woensdag 12 oktober 2016 12:55 > To: Subversion Development <dev@subversion.apache.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 > Complete > 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 > Complete > 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 > Complete > 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.
