Re: Efficient revprop access in lib_repos

2015-10-12 Thread Stefan Fuhrmann
On Mon, Oct 12, 2015 at 12:10 AM, Bert Huijben wrote: > Hi, > > > > Another reply: > > > > How does this affect multiple processes accessing the same repository? > For FSFS: The effect is the same as using 2 different svn_fs_t instances because the cache uses a svn_fs_t-specific

RE: Efficient revprop access in lib_repos

2015-10-11 Thread Bert Huijben
Hi, Another reply: How does this affect multiple processes accessing the same repository? This caching looks like a nice speedup in some common cases, but I’m wondering if we are adding new race conditions on revision property updates. We had to add specific atomic rev

Re: Efficient revprop access in lib_repos

2015-10-11 Thread Stefan Fuhrmann
On Sun, Oct 11, 2015 at 3:29 PM, Bert Huijben wrote: > Why a uuid and not just some int64 atomic incrementation value that is > cached ir similar. > You are right, anything "unique enough" will do and the code can easily be changed to using and i64 later. I'll do that right after my commit queue

RE: Efficient revprop access in lib_repos

2015-10-11 Thread Bert Huijben
Why a uuid and not just some int64 atomic incrementation value that is cached ir similar. Generating a uuid is not something that is not measurable performance wise. It might take some expensive interproces communication or even hardware access. Bert -Original Message- From: "Stefan Fu