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:[email protected]]
Sent: woensdag 12 oktober 2016 12:55
To: Subversion Development <[email protected]>
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 <http://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 <http://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 <http://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 <http://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 <http://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 <http://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 <http://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 <http://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 <http://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 <http://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 <http://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.
