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
> -Original Message-
> From: stef...@apache.org [mailto:stef...@apache.org]
> Sent: zondag 11 oktober 2015 19:11
> To: comm...@subversion.apache.org
> Subject: svn commit: r1708003 - in
> /subversion/trunk/subversion/libsvn_repos: commit.c fs-wrap.c load-fs-
> vtable.c rev_hunt.c
>
> Aut
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
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
[This is the rationale and additional documentation to an upcoming
set of commits.]
When changing a revprop, we provide the following visibility guarantees:
1. A request that ends before the set_revprop started, sees the old value
(duh!).
2. A request that starts after the set_revprop completes,
On Thu, Oct 8, 2015 at 1:07 PM, Evgeny Kotkov
wrote:
> Stefan Fuhrmann writes:
>
> > This is not about performance, it is about API guarantees and functional
> > stability. So, yes that is an optimization in the sense of "making it
> better
> > than before". And no, we should not go back to wors
6 matches
Mail list logo
