Re: Proposal: new fsfs.conf properties

Philip Martin wrote on Thu, 13 Jul 2017 21:36 +0100: > Branko Čibej writes: > > > Whether this actually forces a format bump or not is a different > > question which I don't know the answer to. > > I think we would have to bump. The old code could either read the > pre-delta

Re: Proposal: new fsfs.conf properties

Branko Čibej writes: > Whether this actually forces a format bump or not is a different > question which I don't know the answer to. I think we would have to bump. The old code could either read the pre-delta or the post-delta files, depending on how we decided to name

Re: Proposal: new fsfs.conf properties

On 13.07.2017 21:57, Philip Martin wrote: > Branko Čibej writes: > >> Agreed. That's why I didn't propose this. I proposed spawning off a >> daemon that would post-process _one_ commit and exit. It could do all >> sorts of analysis of the content and finding the best (for some

Re: Proposal: new fsfs.conf properties

Branko Čibej writes: > Agreed. That's why I didn't propose this. I proposed spawning off a > daemon that would post-process _one_ commit and exit. It could do all > sorts of analysis of the content and finding the best (for some > definition of "best") source for the delta,

Re: Proposal: new fsfs.conf properties

On 13.07.2017 20:42, Paul Hammant wrote: > A Janitor process that runs independently of Apache isn't a /paradigm > shift/ but it is a huge amount of work to production harden, even if > it was done in today's new hotness Go or Rust. As is the minefield of > maintaining a list that's persistent of

Re: Proposal: new fsfs.conf properties

On 13.07.2017 20:24, Paul Hammant wrote: > Is Mod_Dav_Svn a TSR* thing? Or wholly re-entered for each request > that would require it? > > * https://en.wikipedia.org/wiki/Terminate_and_stay_resident_program > Well since it doesn't run on DOS, it's not TSR :) mod_dav_svn is a shared library

Re: Proposal: new fsfs.conf properties

Is Mod_Dav_Svn a TSR* thing? Or wholly re-entered for each request that would require it? * https://en.wikipedia.org/wiki/Terminate_and_stay_resident_program On Thu, Jul 13, 2017 at 2:11 PM, Branko Čibej wrote: > On 13.07.2017 16:07, Daniel Shahaf wrote: > > On Thu, Jul 13,

Re: Tip of the day: Cheatsheet for common cmdline client operations

With respect to the author and the work he's done, I'm not really interested in us maintaining yet *another* collection of the same information already covered -- in some cases multiple times, when you factor in the reference sections -- by the book. At best this cheatsheet would be an appendix.

Re: Tip of the day: Cheatsheet for common cmdline client operations

[moving from users@ ] Daniel Shahaf wrote on Fri, 30 Jun 2017 09:15 +: > I just ran into the following cheatsheet: > > http://www.chim.unifi.it/~signo/did/etc/subversion/neat.html > > It covers the normal multi-user workflow, branching, etc.. > > (Kudos to the author, Giorgio Signorini,

Re: Proposal: new fsfs.conf properties

On Thu, Jul 13, 2017 at 06:34:17AM -0400, Paul Hammant wrote: > Or am I really wanting Svn's backend compression and deltification to be > out of band ? > > 1. compression-strategy = defer-to-idle-time-even-if-days-later > 2. deltification-strategy = defer-to-idle-time-even-if-days-later

Re: Proposal: new fsfs.conf properties

Philip Martin writes: > A proper v2 client, such as the Subversion > libraries, will send OPTIONS and parse the response to identify > features. Each transaction has server-side state on disk. A Subversion client will attempt to delete the transaction if an error

Re: Proposal: new fsfs.conf properties

Paul Hammant writes: > Sweet - I'll operationalize that ASAP. The client side of the sync agent > knows whether the item is new or to be changed, already. Protocol details: http://svn.apache.org/repos/asf/subversion/trunk/notes/http-and-webdav/http-protocol-v2.txt POST is

Re: Proposal: new fsfs.conf properties

On Thu, Jul 13, 2017 at 12:34 PM, Paul Hammant wrote: >> >> >> Mmm ... interesting proposition. Also huge -1 because it'd be a really >> awesome abstraction leak. :) > > > > Is there any way to implement the (reasonable in my opinion) feature > request, without transgressing on

Re: Proposal: new fsfs.conf properties

On 13.07.2017 14:12, Paul Hammant wrote: > Sweet - I'll operationalize that ASAP. The client side of the sync > agent knows whether the item is new or to be changed, already. To be quite clear here: If you don't need history, you might consider using a different DAV backend than Subversion.

Re: Proposal: new fsfs.conf properties

Sweet - I'll operationalize that ASAP. The client side of the sync agent knows whether the item is new or to be changed, already. - Paul > > > Sorry I'm gunna be a bit slow here, Philip, but you're saying that > sequence > > of four is a single atomic commit in Subversion? > > Yes. > >

Re: Proposal: new fsfs.conf properties

Paul Hammant writes: > Sorry I'm gunna be a bit slow here, Philip, but you're saying that sequence > of four is a single atomic commit in Subversion? Yes. -- Philip

Re: Proposal: new fsfs.conf properties

I don't mind how it's implemented, and agree this one is weak. I am after a solution though and am open to alternate ideas if compression-exempt-suffixes and its sibling cannot be implemented for some technical reason. On Thu, Jul 13, 2017 at 7:54 AM, Branko Čibej wrote: > On

Re: Proposal: new fsfs.conf properties

On 13.07.2017 13:07, Paul Hammant wrote: > > > The delete+recreate takes the same 5.2s as the original create and is > faster than curl's 6.7s update. > > > New fsfs config prop ? > > delete_and_recreate_instead_of_change_threshold = 50MB You forgot the smiley here, surely you're

Re: Proposal: new fsfs.conf properties

Sorry I'm gunna be a bit slow here, Philip, but you're saying that sequence of four is a single atomic commit in Subversion? - Paul On Thu, Jul 13, 2017 at 7:48 AM, Philip Martin wrote: > Philip Martin writes: > > > The fact that the create

Re: Proposal: new fsfs.conf properties

Philip Martin writes: > The fact that the create is faster than the update means that if > uploading the data is the only thing that matters then breaking the > history and changing the update into a delete+recreate is faster, i.e. > > svnmucc -mm -U

Re: Proposal: new fsfs.conf properties

> > > The delete+recreate takes the same 5.2s as the original create and is > faster than curl's 6.7s update. > > New fsfs config prop ? delete_and_recreate_instead_of_change_threshold = 50MB -ph

Re: Proposal: new fsfs.conf properties

Johan Corveleyn writes: > 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: Using a trunk build, I'm uploading

Re: Big files PUT into Subversion - encountering

Markus - you may be right on hopes for perf improvements. I'm reevaluating what I said a couple of days ago in this thread. The best case PUT times for that 15GB random resource at *7 mins*, but about 1/5 of them are at *15 mins*. I'm going to try to undo the TMPDIR change and see if it goes back

Re: Proposal: new fsfs.conf properties

> > > > Mmm ... interesting proposition. Also huge -1 because it'd be a really > awesome abstraction leak. :) > Is there any way to implement the (reasonable in my opinion) feature request, without transgressing on programming standards? I think turning off all deltification is a bit brute

Re: Proposal: new fsfs.conf properties

On rationale ... This is a file sync agent. 600 lines of Python that I'm going to open source. The same thing I was working on in 2016 when I chatting on this list. Goals: 1) *not have two copies of everything on the clien*t, 2) have different semantics to pushing back changed files. Secondary

Re: Proposal: new fsfs.conf properties

On Thu, Jul 13, 2017 at 9:36 AM, Johan Corveleyn wrote: > > On Thu, Jul 13, 2017 at 8:27 AM, Branko Čibej 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.

Re: Proposal: new fsfs.conf properties

On Thu, Jul 13, 2017 at 8:27 AM, Branko Čibej 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

Re: Proposal: new fsfs.conf properties

Branko Čibej wrote: Paul Hammant wrote: I'd love a --header "svn:message: my message" [...] I'm wondering what you gain [...] Paul, I encourage you to start a new thread if any further discussion of this point is needed. - Julian

Re: Proposal: new fsfs.conf properties

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

Re: Proposal: new fsfs.conf properties

On 12.07.2017 21:50, Paul Hammant wrote: > You know, in all seriousness I think the (empty by default) list of > exempted files suffixes the the best way forward. If suffixes is good > enough for Apache itself to use (link provided earlier), it is good > enough in this scenario on the server side