On Thu, Jul 13, 2017 at 9:36 AM, Johan Corveleyn <jcor...@gmail.com> wrote: > > On Thu, Jul 13, 2017 at 8:27 AM, Branko Čibej <br...@apache.org> wrote: > > On 13.07.2017 04:07, Paul Hammant wrote: > >> I flipped _back_ to Python's requests.put(..) in my solution - from a > >> regular Svn client. That relies on 'autoversioning=on' for it to work > >> over DAV, I mean. In that configuration it functions like curl, of > >> course. > >> > >> _Commit Messages_ > >> > >> I'd love a --header "svn:message: my message" too. I raised it before > >> in https://issues.apache.org/jira/browse/SVN-4454 > >> <https://issues.apache.org/jira/browse/SVN-4454> but the team was > >> split back in 2013 on yes vs no. I'm thinking I'd like it again, > >> having reviewed all the comments. Can I ask for that issue/request to > >> be reopened, please ? > > > > > > I'm wondering what you gain with curl and autoversioning over, e.g., > > svnmucc or using our bindings (or even our libraries)? Other than that > > you can't set the log message or any other properties. > > > > FWIW, I strongly disagree with the idea of adding this feature, given > > that there are already _two_ ways of doing this without having a working > > copy. > > As I said in my previous response here, I think the reason for Paul to > go for curl+autoversioning is speed, because it eliminates client-side > deltification. It was suggested and demonstrated by Philip here: > > https://svn.haxx.se/dev/archive-2017-07/0040.shtml > > But I'm wondering if that curl advantage won't dissapear if we develop > a solution for a normal svn client to skip deltification.
Keen to understand this - speeding up commits in a supported way (for specific workflows) would be a major win. > > -- > Johan