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). >