On 10/28/2012 01:54 AM, Daniel Shahaf wrote:
Index: subversion/libsvn_fs/fs-loader.c
===
--- subversion/libsvn_fs/fs-loader.c(revision 1402414)
+++ subversion/libsvn_fs/fs-loader.c(working copy)
@@ -487,17 +487,21 @@
On Mon, Oct 29, 2012 at 12:27:32PM +0530, Prabhu Gnana Sundar wrote:
> On 10/28/2012 01:54 AM, Daniel Shahaf wrote:
> >>Index: subversion/libsvn_fs/fs-loader.c
> >>===
> >>--- subversion/libsvn_fs/fs-loader.c(revision 1402414)
On 10/29/2012 02:51 PM, Stefan Sperling wrote:
On Mon, Oct 29, 2012 at 12:27:32PM +0530, Prabhu Gnana Sundar wrote:
On 10/28/2012 01:54 AM, Daniel Shahaf wrote:
Index: subversion/libsvn_fs/fs-loader.c
===
--- subversion/libsvn_fs/f
On Mon, Oct 29, 2012 at 03:26:36PM +0530, Prabhu Gnana Sundar wrote:
> Thanks much Stefan,
>
> Now, I have changed the code in libsvn_fs/fs-loader.c to handle the
> error. Passed the keep_going to the verify_fs so that it can be
> handled in both libsvn_fs_fs and libsvn_fs_base. I have attached th
1.7.0@1181106 vs. trunk@1402896
Started at Mon Oct 29 11:27:32 UTC 2012
*Disclaimer* - This tests only file://-URL access on a GNU/Linux VM.
This is intended to measure changes in performance of the local working
copy layer, *only*. These results are *not* generally true for everyone.
Averaged-to
Sean Farrell writes:
> Will this fix go out in a 1.7.8 and/or 1.8?
I've committed it to trunk (1.8) and proposed it for 1.7.
> Also, I'm trying to track down what releases have this bug. It looks
> like starting with 1.6.12 on up, which includes all of 1.7.x
> (i.e. 1.7.0 - 1.7.7). Is that corr
Hi all,
working around a weird buglet in matplotlib (r1403277), I've finally
produced the first chart on our libsvn_wc-benchmark-running svn-qavm:
http://svn-qavm.apache.org/charts/
My intention is to further improve and automate, but there you have the
first bit of graph to look at!
~Neels
I'm getting random regression test fails in parallel mode due to a race
in svn_atomic_namespace__create:
W: ERROR: dump failed: ../src/subversion/libsvn_fs_fs/fs_fs.c:3220:
(apr_err=160052)
W: ERROR: dump failed: svnadmin: E160052: Revprop caching for
'svn-test-work/local_tmp/repos/db' disable
Thank you so much Stefan for your patience in reviewing and guiding me
through.
I have addressed your points in the patch attached in this mail. I hope
I addressed all the suggestions given by you :)
Please share your views.
I will come up with a test case for this implementation in a new p
On Mon, Oct 29, 2012 at 10:45:19PM +0530, Prabhu Gnana Sundar wrote:
>
> Thank you so much Stefan for your patience in reviewing and guiding
> me through.
>
> I have addressed your points in the patch attached in this mail. I
> hope I addressed all the suggestions given by you :)
> Please share y
Stefan Sperling wrote on Mon, Oct 29, 2012 at 19:23:46 +0100:
> Looks great otherwise!
The docstring for svn_repos_fs_verify3() refers to stderr.
(It should talk about "making a notification" instead - the library
never touches stderr)
HI Neels,
Nice work!
I am often asked how the speed improvements are going.
People still seem to be holding onto the speed of the 1.4 era - and calling
out SubVersion as being too slow to use.
Something like this is very handy.
Thanks.
> -Original Message-
> From: Neels J Hofmeyr [mailt
Philip Martin writes:
> I can't see any order in which we can do attach/create that doesn't have
> a similar race. I think the best solution is a short loop trying
> attach-create a few times before giving up.
I've committed a loop in r1403463. That doesn't fix the race but it is
now very unli
On Fri, Oct 5, 2012 at 3:10 PM, Ben Reser wrote:
> b) Sinsheim, Germany November 5th - 8th at ApacheCon EU 2012.
>
> I plan on organizing key signing at both events if there is sufficient
> people interested and there will be keys that need signing. Given the
> issue the SHA-1 issue described a
Monday November 5th is setup as a Hackathon for ApacheCon. I've added
the Subversion project to the list of proposed Hackathon's here:
http://wiki.apache.org/apachecon/HackathonEU12
If you're planning to come please adjust the number of interested
people. Also feel free to adjust the description
Interesting. I'll join you guys, plan to work on fixes for serf issues.
So, general note: any serf issues you might encounter, log them before
or during next week and I'll be try to solve them during next week.
Lieven
On Mon, Oct 29, 2012 at 9:51 PM, Ben Reser wrote:
> Monday November 5th is se
Please be sure to +1 the Interest count on that wiki if you're coming.
If there's enough interest then the organizers will make us a sign
and dedicate a table to us.
On Mon, Oct 29, 2012 at 2:13 PM, Lieven Govaerts wrote:
> Interesting. I'll join you guys, plan to work on fixes for serf issues.
In several places in ra_serf I see the pattern:
/* Skip on to the next iteration of this loop. */
if (APR_STATUS_IS_EAGAIN(status))
{
return svn_ra_serf__wrap_err(status, NULL);
}
continue;
Is that test co
On Mon, Oct 29, 2012 at 10:27 PM, Ben Reser wrote:
> Please be sure to +1 the Interest count on that wiki if you're coming.
> If there's enough interest then the organizers will make us a sign
> and dedicate a table to us.
done
[..]
Philip Martin writes:
> Philip Martin writes:
>
>> I can't see any order in which we can do attach/create that doesn't have
>> a similar race. I think the best solution is a short loop trying
>> attach-create a few times before giving up.
>
> I've committed a loop in r1403463. That doesn't fix
On Mon, Oct 29, 2012 at 10:46 PM, Philip Martin
wrote:
> Philip Martin writes:
>
> > Philip Martin writes:
> >
> >> I can't see any order in which we can do attach/create that doesn't have
> >> a similar race. I think the best solution is a short loop trying
> >> attach-create a few times befor
Philip Martin writes:
> In several places in ra_serf I see the pattern:
>
> /* Skip on to the next iteration of this loop. */
> if (APR_STATUS_IS_EAGAIN(status))
> {
> return svn_ra_serf__wrap_err(status, NULL);
> }
>
Stefan Fuhrmann writes:
> On Mon, Oct 29, 2012 at 10:46 PM, Philip Martin
> wrote:
>
>> Philip Martin writes:
>>
>> > Philip Martin writes:
>> >
>> >> I can't see any order in which we can do attach/create that doesn't have
>> >> a similar race. I think the best solution is a short loop trying
On 10/29/2012 05:31 PM, Philip Martin wrote:
> In several places in ra_serf I see the pattern:
>
> /* Skip on to the next iteration of this loop. */
> if (APR_STATUS_IS_EAGAIN(status))
> {
> return svn_ra_serf__wrap_err(status, NULL);
>
Philip Martin writes:
> Stefan Fuhrmann writes:
>
>> The creation code is protected by a repo-global lock/unlock pair.
>> So, in theory, there should be no race condition.
>
> Which lock and where? Does this lock out other processes?
I see it's db/rev-prop-atomicsMutex
>> It's on my TODO list
Just remember: these charts only show the libsvn_wc layer. They don't test
networking at all, ra_local only. That charts place will still be in flux
while I'm maturing the code.
...but otherwise, feel free to share :)
~Neels
On 2012-10-29 19:44, Gavin Baumanis wrote:
> HI Neels,
> Nice work!
>
cmpil...@apache.org wrote on Mon, Oct 29, 2012 at 23:53:21 -:
> Author: cmpilato
> Date: Mon Oct 29 23:53:20 2012
> New Revision: 1403583
>
> URL: http://svn.apache.org/viewvc?rev=1403583&view=rev
> Log:
> Fix the cause of a client-side hang in ra_serf's handling of
> Subversion's custom XML e
Hi Neels,
Thanks for the extra information.
I had been using your bench-marking - just as a "proof" that the speed of
SVN was an ongoing concern for the development team that was actively being
addressed.
And "tada"... here is the numbers prove it still improving.
Thanks again none the less, for
28 matches
Mail list logo
