If you are using dav autoversioning, then why do you want to obtain the sha using 'svn’.
You should be able to obtain the sha using a PROPFIND request against the server. We use that checksum from there to avoid downloading the same file multiple times in our streamlined v2 http protocol. Bert Sent from my Windows 10 phone From: Paul Hammant Sent: dinsdag 11 oktober 2016 14:09 To: Subversion Development Subject: Re: New SHA1 property for nodes returned 'svn ls --xml' invocations. Considering .. svn info --xml https://svn.apache.org/repos/asf/subversion/trunk/subversion/mod_dav_svn/mod_dav_svn.c I would hope for a <sha1> element at root level: <?xml version="1.0" encoding="UTF-8"?> <info> <entry path="mod_dav_svn.c" revision="1764226" kind="file"> <url>https://svn.apache.org/repos/asf/subversion/trunk/subversion/mod_dav_svn/mod_dav_svn.c</url> <relative-url>^/subversion/trunk/subversion/mod_dav_svn/mod_dav_svn.c</relative-url> <repository> <root>https://svn.apache.org/repos/asf</root> <uuid>13f79535-47bb-0310-9956-ffa450edef68</uuid> </repository> <commit revision="1723715"> <content-sha1>3bc64b30547e9a0448feba6c6af48447dff2b980<content-sha1> <author>ivan</author> <date>2016-01-08T12:28:35.243550Z</date> </commit> </entry> </info> Considering .. svn ls --xml https://svn.apache.org/repos/asf/subversion/trunk/subversion/mod_dav_svn/ Similarly resulting in the insertion of <sha1>: <?xml version="1.0" encoding="UTF-8"?> <lists> <list path="https://svn.apache.org/repos/asf/subversion/trunk/subversion/mod_dav_svn";> ... <entry kind="file"> <name>mod_dav_svn.c</name> <size>42444</size> <commit revision="1723715"> <content-sha1>3bc64b30547e9a0448feba6c6af48447dff2b980<content-sha1> <author>ivan</author> <date>2016-01-08T12:28:35.243550Z</date> </commit> </entry> ... </list> </lists> svn-ls doesn't have and entry for "." of course. It's parent has that node, and svn-ls works on directories just fine. For the entry of directory that contains mod_dav_svn.c, I'd hope for the SHA1 to be a function of the SHA1s of the files within. That's Merkle-tree style - a super important feature generally as well as specifically to my use-case. For my use-case to work, I need to have a reasonable chance of recalculating the SHA1 on the client file system without access to the remote repo, or the presence of a .svn directory. That's why I'm calling the element content-sha1. There could be a sibling element complete-sha1 which is the content-sha1 and whatever properties should be included too. I would not use that element, but properties were mentioned before. I don't have an opinion about symlinks, of experience of them with Svn. I'm unfamilar with the hat-syntax wc-centric use of svn-ls. Therefore I don't know what to say about it. I've read the ?kw=1 section of the release notes. My use case would not need keyword replacement. In fact it would need it to be off. Something about something Greek in https://svn.apache.org/repos/asf/subversion/tree/readme ? - I'm lost and need further guidance as to reading materials, please. Regards, - Paul On Tue, Oct 11, 2016 at 2:40 AM, Daniel Shahaf <danie...@apache.org> wrote: Paul Hammant wrote on Mon, Oct 10, 2016 at 22:23:25 -0400: > In that page, there is a mention of 'ModMimeUsePathInfo' that can add > properties transparently. One like it could optionally add a sha1 as a > property and that be transient like svn:log, svn:date and svn:author. > Please don't worry about implementation details at this stage. Adding a per-file attribute is easy. (It won't be like svn:log, however, because that is a revprop, as opposed to a nodeprop.) The real question is, what information you are asking to be provided. Given the standard Greek tree (see subversion/tests/README), what would be the outputs of «svn ls --xml ^/iota» and «svn ls --xml ^/A/»? Are you asking for information to be provided for plain files? For symlinks? For directories? What is the value of the new attribute in each of those cases? If it's a checksum, is it the repository-normal version or the keywords-expanded version (like ?kw=1 in mod_dav_svn, see 1.8 release notes)? Don't worry about how the information would be encoded on the wire; just about what information you would like to have on the client. Cheers, Daniel > Re the commands svn-ls and svn-info. They have an --xml flag already, and > it would be cool if there was a way of adding select properties to that. > Note that --xml and --show-item fight each other presently (and are > singular).
