[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: New SHA1 property for nodes returned 'svn ls --xml' invocations.

From: Paul Hammant <paul_at_hammant.org>
Date: Tue, 11 Oct 2016 08:09:06 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.