On 09.03.2012 17:12, Philip Martin wrote:
Stefan Fuhrmann writes:
* new definition: generations must be even numbered
* writer stores timeout value (e.g. now() + 10s)
* writer increments generation -> odd number
(if the result is an even number, there are concurrent
writes or one proce
Stefan Fuhrmann writes:
> * new definition: generations must be even numbered
> * writer stores timeout value (e.g. now() + 10s)
> * writer increments generation -> odd number
> (if the result is an even number, there are concurrent
>writes or one process crashed; increment until we
>re
On 08.03.2012 10:26, Philip Martin wrote:
Stefan Fuhrmann writes:
* undo the above-mentioned revs on /trunk
Good. I was starting to have concerns about other races in the current
code. For example:
- first process reads generation file N
- second process writes new revprops
- first
Hi, Stefan,
Von: Stefan Fuhrmann [mailto:eq...@web.de]
>On 08.03.2012 08:54, Markus Schaber wrote:
> On 08.03.2012 02:13, Bert Huijben wrote:
> And this shared mem approach will work with both threaded as well
> as multi-process servers?
> If so, this sounds like a good plan to me.
>
Development
Subject: Re: Revprop caching 'n stuff
On Wed, Mar 07, 2012 at 11:40:40PM +0100, Stefan Fuhrmann wrote:
Hi all,
And this shared mem approach will work with both threaded as well as
multi-process servers?
If so, this sounds like a good plan to me.
This still assumes that the reposito
On 08.03.2012 08:54, Markus Schaber wrote:
Hi,
On 08.03.2012 02:13, Bert Huijben wrote:
And this shared mem approach will work with both threaded as well as
multi-process servers?
If so, this sounds like a good plan to me.
This still assumes that the repository is only used by a single
machine
gt; >>Cc: Subversion Development
> >>Subject: Re: Revprop caching 'n stuff
> >>
> >>On Wed, Mar 07, 2012 at 11:40:40PM +0100, Stefan Fuhrmann wrote:
> >>>Hi all,
> >
> >>And this shared mem approach will work with both threaded as well
Stefan Fuhrmann writes:
> * undo the above-mentioned revs on /trunk
Good. I was starting to have concerns about other races in the current
code. For example:
- first process reads generation file N
- second process writes new revprops
- first process reads revprops
- second process wri
Hi,
On 08.03.2012 02:13, Bert Huijben wrote:
>>> And this shared mem approach will work with both threaded as well as
>>> multi-process servers?
>>> If so, this sounds like a good plan to me.
>> This still assumes that the repository is only used by a single
>> machine, while using NFS paths wit
On 08.03.2012 02:13, Bert Huijben wrote:
-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: donderdag 8 maart 2012 1:28
To: Stefan Fuhrmann
Cc: Subversion Development
Subject: Re: Revprop caching 'n stuff
On Wed, Mar 07, 2012 at 11:40:40PM +0100, Stefan Fuh
> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: donderdag 8 maart 2012 1:28
> To: Stefan Fuhrmann
> Cc: Subversion Development
> Subject: Re: Revprop caching 'n stuff
>
> On Wed, Mar 07, 2012 at 11:40:40PM +0100, Stefan Fuhrma
On 08.03.2012 01:28, Stefan Sperling wrote:
On Wed, Mar 07, 2012 at 11:40:40PM +0100, Stefan Fuhrmann wrote:
Hi all,
The revprop caching I introduced in r1296604, -10
plus -7211 (kudos to Daniel) has an issue when it
comes to making long-lived fs_t detect revprop
changes. OTOH, I think that it
On Wed, Mar 07, 2012 at 11:40:40PM +0100, Stefan Fuhrmann wrote:
> Hi all,
>
> The revprop caching I introduced in r1296604, -10
> plus -7211 (kudos to Daniel) has an issue when it
> comes to making long-lived fs_t detect revprop
> changes. OTOH, I think that it also provides a huge
> performance
Hi all,
The revprop caching I introduced in r1296604, -10
plus -7211 (kudos to Daniel) has an issue when it
comes to making long-lived fs_t detect revprop
changes. OTOH, I think that it also provides a huge
performance boost when you use clients like TSVN
that fire a large number of "svn ls -v"-e
14 matches
Mail list logo
