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 

We use that checksum from there to avoid downloading the same file multiple 
times in our streamlined v2 http protocol.


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 

I would hope for a <sha1> element at root level:

<?xml version="1.0" encoding="UTF-8"?>

Considering ..

svn ls --xml 

Similarly resulting in the insertion of <sha1>:

<?xml version="1.0" encoding="UTF-8"?>





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.


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



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

Reply via email to