Greg Stein writes:
> On Tue, Mar 8, 2011 at 11:08, Philip Martin
> wrote:
>> VTXN operation:
>>
>> - client sends POST
>> - proxy adds SVN-VTxn-Name:UUID
>> - server creates transaction called TXN-NAME
>> - server replies SVN-VTxn-Name:UUID
>> - proxy passes
>
> or:
>
> - proxy adds: SVN
Stefan Fuhrmann writes:
> On 08.03.2011 14:46, Philip Martin wrote:
>> stef...@apache.org writes:
>>
>>> Author: stefan2
>>> Date: Mon Mar 7 22:57:04 2011
>>> New Revision: 1079008
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1079008&view=rev
>>> Log:
>>> Set FSFS cache default size to 16 MB. T
On Wed, Mar 9, 2011 at 04:40, Philip Martin wrote:
> Greg Stein writes:
>...
>> Basically, the server is responding with somebody the requestor
>> already knows. So I wonder which approach is "best". It seems to be
>> kinda six-of-one/half-dozen-of-another. I suspect the server just
>> needs an i
Greg Stein writes:
> The proxy is the one altering the request/response flow. From the
> server's standpoint, the client (in this case, the proxy) already
> knows the name. Why should the server tell it what it already knows?
> Why should it put that useless information onto the wire?
It's conve
Philip Martin writes:
> Greg Stein writes:
>
>> The proxy is the one altering the request/response flow. From the
>> server's standpoint, the client (in this case, the proxy) already
>> knows the name. Why should the server tell it what it already knows?
>> Why should it put that useless informa
On Wed, Mar 09, 2011 at 10:51:19AM +0530, Noorul Islam K M wrote:
> I fixed the warning issue. Is there anything else do be done with this
> patch?
Nothing, thank you. I've committed it in r1079758, but accidentally
used the old version. r1079759 adds the braces again (sorry about that).
On Wed, Mar 9, 2011 at 06:43, Philip Martin wrote:
> Philip Martin writes:
>
>> Greg Stein writes:
>>
>>> The proxy is the one altering the request/response flow. From the
>>> server's standpoint, the client (in this case, the proxy) already
>>> knows the name. Why should the server tell it what
Greg Stein writes:
> Wait a minute. The svn client won't ever send this. So I'm not sure
> what you mean by "client send path" here, or "requiring ... the use of
> a proxy".
>
> Your request for this feature is entirely predicated on a proxy. So of
> course you need a proxy. And the client is nev
On Wed, Mar 9, 2011 at 5:48 AM, Stefan Sperling wrote:
> On Wed, Mar 09, 2011 at 10:51:19AM +0530, Noorul Islam K M wrote:
>> I fixed the warning issue. Is there anything else do be done with this
>> patch?
>
> Nothing, thank you. I've committed it in r1079758, but accidentally
> used the old vers
Log
[[[
* notes/xfail-status: Remove entry of test for issue #3792. Test passes now.
]]]
Thanks and Regards
Noorul
Index: notes/xfail-status
===
--- notes/xfail-status (revision 1079793)
+++ notes/xfail-status (working copy)
@@
Hyrum K Wright writes:
> On Wed, Mar 9, 2011 at 5:48 AM, Stefan Sperling wrote:
>
>> On Wed, Mar 09, 2011 at 10:51:19AM +0530, Noorul Islam K M wrote:
>>> I fixed the warning issue. Is there anything else do be done with this
>>> patch?
>>
>> Nothing, thank you. I've committed it in r1079758, bu
On Wed, 09 Mar 2011, Avalon wrote:
[quoting cmpilato:]
2. Consider deletion events as "interesting history points"
when displaying the revisions logs for a given path. [...]
BTW, I don't think that solving (2) is realistic at this point.
But filing an issue about it cannot hurt.
Since i h
On Wed, Mar 09, 2011 at 07:25:41PM +0530, Noorul Islam K M wrote:
>
> Log
> [[[
>
> * notes/xfail-status: Remove entry of test for issue #3792. Test passes now.
>
> ]]]
Thanks, committed in r1079803.
On Wed, 2011-03-09, Gavin Beau Baumanis wrote:
> Do you see any scope for the PM to perhaps take up the task of chasing
> up this sort of thing on behalf of the SubVersion project?
[...]
> Ask about, "Should the Patch Manager be the liaison between SubVersion
> and other projects". Only in so far a
On Tue, Mar 8, 2011 at 2:59 PM, Gavin Beau Baumanis
wrote:
> On 09/03/2011, at 2:03 AM, Hyrum K Wright wrote:
>
>> On Tue, Mar 8, 2011 at 2:46 AM, Simon Wilson wrote:
>>>
> On Mon, Mar 07, 2011 at 08:59:35AM +0100, Simon Wilson wrote:
>> I'm posting here for feedback before opening an iss
Philip Martin writes:
> So both serf-0.3 and serf-0.7 are slower than neon.
I've been doing a little investigation. Start with a directory
containing 100 text files:
rm -rf zz;mkdir zz;for i in `seq 0 99`;do printf "abc" > zz/f$i;done
Import that directory using serf and neon and the times ar
On ... wrote:
>...
> Was there any discussion about this overcommit behaviour?
This is the second or third time that I've seen "was there any
discussion" raised as a point. This raises a small yellow flag for me.
We all make changes to the codebase, and many of them are *NOT*
discussed before hand
On Tue, Mar 8, 2011 at 11:14, Stefan Sperling wrote:
>...
> Fair enough, but it should still be opt-in.
> We could add a config directive in ~/.subversion/config.
> If it turns out to be beneficial, users will enable it.
> However, since ra_local is used mostly for testing I don't expect this
> to
On Wed, Mar 9, 2011 at 18:53, Philip Martin wrote:
> Philip Martin writes:
>
>> So both serf-0.3 and serf-0.7 are slower than neon.
>
> I've been doing a little investigation. Start with a directory
> containing 100 text files:
>
> rm -rf zz;mkdir zz;for i in `seq 0 99`;do printf "abc" > zz/f$i;
Ivan Zhakov writes:
> That's really interesting. Could you provide similiar strace for neon?
Neon:
0.000149 sendto(3, "PUT /obj/repo/!svn/wrk/b93b2d01-8"..., 501, 0, NULL,
0) = 501 <0.002280>
0.002360 lseek(5, 0, SEEK_SET) = 0 <0.13>
0.54 read(5, "SVN\0\0\0\3\1\3\203
On Wed, Mar 9, 2011 at 8:28 AM, Philip Martin
wrote:
> 0.54 epoll_wait(3, {{EPOLLOUT, {u32=30583944, u64=30583944}}}, 16,
> 36) = 1 <0.11>
As best as I can tell, that strace isn't matching your earlier
description. The last epoll_wait is taking 0.11 seconds? --
justin
Justin Erenkrantz writes:
> On Wed, Mar 9, 2011 at 8:28 AM, Philip Martin
> wrote:
>> 0.54 epoll_wait(3, {{EPOLLOUT, {u32=30583944, u64=30583944}}}, 16,
>> 36) = 1 <0.11>
>
> As best as I can tell, that strace isn't matching your earlier
> description. The last epoll_wait i
On Wed, Mar 9, 2011 at 8:57 AM, Philip Martin
wrote:
> You are not looking at the right epoll_wait, look 14 lines down from the
> start. That epoll_wait call takes <0.039952>. The line below that
> shows a delay of 0.040042 to the subsequent read call. So epoll_wait is
> responsible for nearly
On Wed, Mar 09, 2011 at 08:50:37AM -0800, Justin Erenkrantz wrote:
> On Wed, Mar 9, 2011 at 8:28 AM, Philip Martin
> wrote:
> > 0.54 epoll_wait(3, {{EPOLLOUT, {u32=30583944, u64=30583944}}}, 16,
> > 36) = 1 <0.11>
>
> As best as I can tell, that strace isn't matching your ear
Joe Orton writes:
> On Wed, Mar 09, 2011 at 08:50:37AM -0800, Justin Erenkrantz wrote:
>> On Wed, Mar 9, 2011 at 8:28 AM, Philip Martin
>> wrote:
>> > 0.54 epoll_wait(3, {{EPOLLOUT, {u32=30583944, u64=30583944}}}, 16,
>> > 36) = 1 <0.11>
>>
>> As best as I can tell, that st
Bert & Greg - OK?
Index: subversion/libsvn_wc/wc-metadata.sql
===
--- subversion/libsvn_wc/wc-metadata.sql(revision 1079778)
+++ subversion/libsvn_wc/wc-metadata.sql(working copy)
@@ -184,15 +184,11 @@
/* --
Greg Stein writes:
> We make changes. We break the code. We make it worse. We fix it, and
> move on.
Thanks, Greg. I certainly don't want Stefan to feel that I am putting
barriers in his way. I probably should have put more effort into
getting my questions right.
--
Philip
On Wed, Mar 9, 2011 at 9:12 AM, Philip Martin
wrote:
> Joe Orton writes:
>
>> On Wed, Mar 09, 2011 at 08:50:37AM -0800, Justin Erenkrantz wrote:
>>> On Wed, Mar 9, 2011 at 8:28 AM, Philip Martin
>>> wrote:
>>> > 0.54 epoll_wait(3, {{EPOLLOUT, {u32=30583944, u64=30583944}}},
>>> > 16, 36
While investigating the newly opened issue #3830[1], I found myself very
quickly running into wall after wall with the approach I'd hoped to take.
The more I thought about and attempted to classify the problems I was
seeing, the more something became apparent to me: the svn_repos_get_logsX()
API c
On Tue, Mar 8, 2011 at 22:07, Greg Stein wrote:
> On Tue, Mar 8, 2011 at 12:34, Ivan Zhakov wrote:
>>...
>> It seems I found reason why ra_serf is slower than ra_neon. ra_serf
>> sends CHECKOUT request for _each_ folder and file that being imported,
>> while ra_neon perform it only for root direc
On 09/03/2011 20:17, Ivan Zhakov wrote:
> On Tue, Mar 8, 2011 at 22:07, Greg Stein wrote:
>> On Tue, Mar 8, 2011 at 12:34, Ivan Zhakov wrote:
>>> ...
>>> It seems I found reason why ra_serf is slower than ra_neon. ra_serf
>>> sends CHECKOUT request for _each_ folder and file that being imported,
On Wed, Mar 9, 2011 at 15:17, Ivan Zhakov wrote:
> On Tue, Mar 8, 2011 at 22:07, Greg Stein wrote:
>> On Tue, Mar 8, 2011 at 12:34, Ivan Zhakov wrote:
>>>...
>>> It seems I found reason why ra_serf is slower than ra_neon. ra_serf
>>> sends CHECKOUT request for _each_ folder and file that being i
On Wed, Mar 9, 2011 at 17:17, wrote:
> Author: pburba
> Date: Wed Mar 9 22:17:10 2011
> New Revision: 1080034
>
> URL: http://svn.apache.org/viewvc?rev=1080034&view=rev
> Log:
> Follow-up to issue #3176 fix in r1079983.
>
> * subversion/libsvn_repos/log.c
>
> (get_combined_mergeinfo_changes): s
I think it is okay, but it *is* a change from 1.6. In a working copy
with two copies of a given repos_relpath, one could be annotated as
"locked" and the other not. Then, running "svn status -u" would give
two different status values for these local nodes (one locked, one
"locked by somebody else")
Thank you!!
On Mar 9, 2011 10:51 AM, wrote:
> Author: hwright
> Date: Wed Mar 9 15:51:16 2011
> New Revision: 1079855
>
> URL: http://svn.apache.org/viewvc?rev=1079855&view=rev
> Log:
> Remove an unused function in the wc_db API. Not only is this function
unused,
> but it also exposes a bit too mu
On Thu, Mar 10, 2011 at 05:36, Greg Stein wrote:
> On Wed, Mar 9, 2011 at 15:17, Ivan Zhakov wrote:
>> On Tue, Mar 8, 2011 at 22:07, Greg Stein wrote:
>>> On Tue, Mar 8, 2011 at 12:34, Ivan Zhakov wrote:
...
It seems I found reason why ra_serf is slower than ra_neon. ra_serf
sends
On Thu, Mar 10, 2011 at 01:23, John Beranek wrote:
> On 09/03/2011 20:17, Ivan Zhakov wrote:
>> On Tue, Mar 8, 2011 at 22:07, Greg Stein wrote:
>>> On Tue, Mar 8, 2011 at 12:34, Ivan Zhakov wrote:
...
It seems I found reason why ra_serf is slower than ra_neon. ra_serf
sends CHECKO
37 matches
Mail list logo
