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 <danielsh_at_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).
>
Received on 2016-10-11 14:09:19 CEST