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

Re: Proposal: new fsfs.conf properties

From: Jacek Materna <jacek_at_assembla.com>
Date: Thu, 13 Jul 2017 11:09:27 +0200

On Thu, Jul 13, 2017 at 9:36 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>
> On Thu, Jul 13, 2017 at 8:27 AM, Branko Čibej <brane_at_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
Received on 2017-07-13 11:10:25 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.