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 <bert_at_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:paul_at_hammant.org]
> Sent: woensdag 12 oktober 2016 12:55
> To: Subversion Development <dev_at_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.
Received on 2016-10-12 14:03:39 CEST