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

Re: SVN and webdav

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Mon, 05 Oct 2020 17:55:19 +0000

Marek Manukjan wrote on Mon, 05 Oct 2020 10:00 +00:00:
> I'm not an expert on SVN's HTTP protocol so I don't know if there is
> another variant of the Commit command like there are two modes of
> Update, but from apache's access log it seems that Commit is done as
> one initial POST request, then each file is uploaded as separate PUT
> request, and the operation is finalized with MERGE request. Someone
> else might want to confirm/disprove this, as it's based purely on
> observation of the access log, not in-depth knowledge.

This is how commits are performed over http when the client and server
are both sufficiently new. There _is_ another way to perform commits
over http, used when either the client or server is older. grep the
source for for "create-txn".

Cheers,

Daniel

> To clear up the difference between using SVNAllowBulkUpdates and
> KeepAlive, as they control separate things:
> * SVNAllowBulkUpdates controls how many HTTP *requests will be done in
> total* for Checkout/Update/Switch operation. It doesn't affect Commit,
> as it seems it always uses multiple requests
> * KeepAlive controls how many HTTP *requests will be done per one TCP
> connection* for any operation
> From your initial question I can't quite make out which of the two you
> want to actually control (not familiar with haproxy), but both should
> be achievable using these configuration attributes.
>
> On Mon, Oct 5, 2020 at 10:49 AM Wokash Wolsku <wokashwolski_at_outlook.com> wrote:
> > This is helpful, thank you, however, reading the links especially SVNAllowBulkUpdates talks of getting the tree. What directives control updates to the tree. The situation I face is that some clients have to up load large graphics files, and video, these will be one object and presumably report request, on first reading that does not appear to be covered by the SVNAllowBulkUpdates.
> >
> > The KeepAlive seem also a corse way to achieve this...
> >
> > Thanks again.
> > *From:* Marek Manukjan <marek.manukjan_at_bisimulations.com>
> > *Sent:* 05 October 2020 10:24
> > *To:* Wokash Wolsku <wokashwolski_at_outlook.com>
> > *Cc:* users_at_subversion.apache.org <users_at_subversion.apache.org>
> > *Subject:* Re: SVN and webdav
> >
> > It depends on server and client configuration. See following configuration attributes
> > * SVNAllowBulkUpdates (On, Off, Prefer)
> > * Bulk update means that all files will be received in a single REPORT request
> > * Non-bulk (Skelta) mode, used by default in newer clients, means that each file will use its own GET request
> > * see https://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default
> > * see http://svnbook.red-bean.com/en/1.7/svn.ref.mod_dav_svn.conf.html
> > * standard Apache configuration attributes KeepAlive, KeepAliveTimeout, MaxKeepAliveRequests
> > * they control how many HTTP requests can be done in a single connection to server
> > * https://httpd.apache.org/docs/2.4/mod/core.html#keepalive
> >
> > On Mon, Oct 5, 2020 at 10:10 AM Wokash Wolsku <wokashwolski_at_outlook.com> wrote:
> >> I am trying to use haproxy to rate control some svn clients which access the SVN repro via svn+https. Some monitoring has thrown up some questions.
> >>
> >> 1. When for example doing a checkout or commit of a large number of files is this implemented as
> >> 1. 1 https request or many
> >> 2. 1 web dav action or many?
> >> 2. from the logs of haproxy (and I am by no means an expert) I see only one connect and one https request.
> >> I was hopping to rate limit the clients by IP address and thereafter http requests hence to slow down large users so others get a share of the processor. But without the volume of up load being related to http requests I am struggling to see how to implement this.
> >>
> >> Can anyone offer any advise.
> >>
> >> Wocash
Received on 2020-10-05 19:55:46 CEST

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

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