You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by cm...@apache.org on 2011/05/18 17:53:04 UTC
svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda
Author: cmpilato
Date: Wed May 18 15:53:04 2011
New Revision: 1124306
URL: http://svn.apache.org/viewvc?rev=1124306&view=rev
Log:
* notes/berlin-11-agenda
Add my first-pass notes about the discussions we've had here in
Berlin. Others may wish to fill in more of the details as they
recall them.
Modified:
subversion/trunk/notes/meetings/berlin-11-agenda
Modified: subversion/trunk/notes/meetings/berlin-11-agenda
URL: http://svn.apache.org/viewvc/subversion/trunk/notes/meetings/berlin-11-agenda?rev=1124306&r1=1124305&r2=1124306&view=diff
==============================================================================
--- subversion/trunk/notes/meetings/berlin-11-agenda (original)
+++ subversion/trunk/notes/meetings/berlin-11-agenda Wed May 18 15:53:04 2011
@@ -5,12 +5,17 @@ discuss, and make themselves merry.
[ should we include an expected attendee list? ]
-Potential items for discussion:
+POTENTIAL ITEMS FOR DISCUSSION
+==============================
+
* Let's finish Subversion 1.7
+ * Externals discussion
* ra_serf issues
- Should we leave serf as default http library?
- Checkout/update editor memory and performance issues. May be
it is worth implementing non-skelta update editor mode in ra_serf.
+ - Serf request ordering problem when re-submitting for authn.
+ - Lack of HTTPS proxy support.
* The P-word
- How important is performance of SVN in comparison to other
qualities like maintainability etc.
@@ -25,5 +30,66 @@ Potential items for discussion:
- Making diff faster (see notes/diff-optimizations.txt)
- Calculating blame info on server side?
- Caching/saving changed-line-info on server side?
- * Externals discussion
* [insert item here]
+
+
+DISCUSSION NOTES
+================
+
+> * Let's finish Subversion 1.7
+
+Hyrum has proposed a branch and release plan on the dev-list:
+http://svn.haxx.se/dev/archive-2011-05/0579.shtml
+
+> * Externals discussion
+
+With regards to the plan for externals, Bert is forsaking his original
+plan to carve externals out of NODES, and is instead using a smaller
+EXTERNALS table to meet the needs. He anticipates completing is work
+here soon. (At this point the collective sigh of relief in the room
+was too noisy to hear anything else.)
+
+> * ra_serf issues
+
+We discussed the general merits of ra_serf (for users, admins, devs,
+etc.). General consensus seems to be that serf is good enough to
+remain the default, but if we get to the 1.7 branch point and we don't
+have ra_serf in a release-ready state (that is, no blocking issues),
+we will revert to ra_neon as the default (on the branch only).
+ra_neon performance has vastly improved recently, and Ivan has still
+more plans for improvement there. But ultimately we know that Serf is
+the path forward, so the sooner we can get the world on it, the more
+quickly we can work out the edge cases.
+
+> * The P-word ("performance")
+
+We're generally accepting of performance changes, but not really at
+the cost of maintainability. That said, "maintainability" isn't the
+opposite of algorithmic complexity. Good documentation and minimal
+obfuscation go a long way toward making complex algorithms and
+approaches maintainable. Also, isolating that complexity helps
+maintainability (versus propogating obscure concepts all over the
+codebase in public APIs, etc.).
+
+As for long-term performance, the oft-asked question is, "Why is
+Subversion so slow when Git is so fast?" We understand that our
+problem space is much more complex than Git's, what with mixed
+revision working copies, path-based authorization, etc. It's not
+realistic to believe that we'll ever be as fast as Git in that
+respect. However, we have already identified several improvements
+that we believe can be made in this area (albeit not in the 1.7
+timeframe).
+
+C-Mike feels that comparison against another tool isn't necessarily
+interesting. It's in the comparison against our users' expectations
+that our battles are lost or won.
+
+The general feel across the group is that 1.7 performance today is,
+for the most part, very pleasing, and arguably ready for release,
+perhaps with a small handful of exceptions ('checkout', for example).
+
+> * 'svn resolve --accept {mine,theirs}-full' for tree conflicts
+> - Now that update skips no tree conflicts, we have a fighting chance.
+
+Stephen Butler is looking at this stuff, but it's not considered a 1.7
+blocker.
Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 05/19/2011 12:54 AM, Lieven Govaerts wrote:
> What is the "serf request ordering problem"? Never heard of any problems
> with that code.
> Lieven
I'd better let Ivan explain that, as it was from he that I learned of the
problem just this morning. Ivan?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda
Posted by Greg Stein <gs...@gmail.com>.
Likewise. We asked Ivan to file a bug about it.
On May 19, 2011 12:55 AM, "Lieven Govaerts" <sv...@mobsol.be> wrote:
> On Wed, May 18, 2011 at 5:53 PM, <cm...@apache.org> wrote:
>
>> Author: cmpilato
>> Date: Wed May 18 15:53:04 2011
>> New Revision: 1124306
>>
>> URL: http://svn.apache.org/viewvc?rev=1124306&view=rev
>> Log:
>> * notes/berlin-11-agenda
>> Add my first-pass notes about the discussions we've had here in
>> Berlin. Others may wish to fill in more of the details as they
>> recall them.
>>
>> Modified:
>> subversion/trunk/notes/meetings/berlin-11-agenda
>>
>> Modified: subversion/trunk/notes/meetings/berlin-11-agenda
>> URL:
>>
http://svn.apache.org/viewvc/subversion/trunk/notes/meetings/berlin-11-agenda?rev=1124306&r1=1124305&r2=1124306&view=diff
>>
>>
==============================================================================
>> --- subversion/trunk/notes/meetings/berlin-11-agenda (original)
>> +++ subversion/trunk/notes/meetings/berlin-11-agenda Wed May 18 15:53:04
>> 2011
>> @@ -5,12 +5,17 @@ discuss, and make themselves merry.
>>
>> [ should we include an expected attendee list? ]
>>
>> -Potential items for discussion:
>> +POTENTIAL ITEMS FOR DISCUSSION
>> +==============================
>> +
>> * Let's finish Subversion 1.7
>> + * Externals discussion
>> * ra_serf issues
>> - Should we leave serf as default http library?
>> - Checkout/update editor memory and performance issues. May be
>> it is worth implementing non-skelta update editor mode in ra_serf.
>> + - Serf request ordering problem when re-submitting for authn.
>>
>
> What is the "serf request ordering problem"? Never heard of any problems
> with that code.
> Lieven
Re: [serf-dev] Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Fri, Jun 3, 2011 at 00:17, Greg Stein <gs...@gmail.com> wrote:
> On Thu, Jun 2, 2011 at 15:57, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> On Wed, May 25, 2011 at 09:28, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>>> On Tue, May 24, 2011 at 6:32 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>>> It's really hard reproduce problem, because it's related to timing of
>>>> sending and receiving requests. From the code my feeling that issue is
>>>> still exists, just in more complicated scenario with more requests but
>>>> I didn't find reproduction script.
>>>
>>> Can you give me an idea why you think the issue still exists? We'd be
>>> adding the new priority requests after all of the previously-queued
>>> (but unwritten) priority requests...so, unless I did a silly think-o,
>>> I don't see why it would if the situation matches what was described
>>> in the issue. -- justin
>>>
>> May be it's different issue, but in case if server doesn't require
>> authentication for all requests and allow anonymous access for some
>> requests:
>> C: GET /restricted/
>> C: GET /public/
>> S: 401 /restricted/
>> S: 200 /public/ (client gets notification that second request is completed)
>> C: GET /restricted
>> S: 200 /restricted (clients gets notification that first request is completed)
>
> I don't see how re-ordering GET requests is a problem. This will
> naturally occur since ra_serf uses multiple connections. The server is
> free to respond to each connection however it wishes. ... and if it
> does so... I'm not sure what actual problem that causes.
>
I agree that it is not a big problem to implement serf client (ra_serf
in our case) to be aware that requests can complete in different
order. But it's a problem of serf since our API promise that requests
will complete in the same order as they created.
You are right that in general ra_serf does not rely on requests
completion order, but:
1. During update we always send PROPFIND and GET requests for one file
on same connection and expect them completed in this order.
2. svnsync replay editor is definitely rely on that requests are
completed in the same order that there are created.
--
Ivan Zhakov
Re: [serf-dev] Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Jun 2, 2011 at 15:57, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Wed, May 25, 2011 at 09:28, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
>> On Tue, May 24, 2011 at 6:32 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>> It's really hard reproduce problem, because it's related to timing of
>>> sending and receiving requests. From the code my feeling that issue is
>>> still exists, just in more complicated scenario with more requests but
>>> I didn't find reproduction script.
>>
>> Can you give me an idea why you think the issue still exists? We'd be
>> adding the new priority requests after all of the previously-queued
>> (but unwritten) priority requests...so, unless I did a silly think-o,
>> I don't see why it would if the situation matches what was described
>> in the issue. -- justin
>>
> May be it's different issue, but in case if server doesn't require
> authentication for all requests and allow anonymous access for some
> requests:
> C: GET /restricted/
> C: GET /public/
> S: 401 /restricted/
> S: 200 /public/ (client gets notification that second request is completed)
> C: GET /restricted
> S: 200 /restricted (clients gets notification that first request is completed)
I don't see how re-ordering GET requests is a problem. This will
naturally occur since ra_serf uses multiple connections. The server is
free to respond to each connection however it wishes. ... and if it
does so... I'm not sure what actual problem that causes.
Cheers,
-g
Re: [serf-dev] Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Wed, May 25, 2011 at 09:28, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Tue, May 24, 2011 at 6:32 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> It's really hard reproduce problem, because it's related to timing of
>> sending and receiving requests. From the code my feeling that issue is
>> still exists, just in more complicated scenario with more requests but
>> I didn't find reproduction script.
>
> Can you give me an idea why you think the issue still exists? We'd be
> adding the new priority requests after all of the previously-queued
> (but unwritten) priority requests...so, unless I did a silly think-o,
> I don't see why it would if the situation matches what was described
> in the issue. -- justin
>
May be it's different issue, but in case if server doesn't require
authentication for all requests and allow anonymous access for some
requests:
C: GET /restricted/
C: GET /public/
S: 401 /restricted/
S: 200 /public/ (client gets notification that second request is completed)
C: GET /restricted
S: 200 /restricted (clients gets notification that first request is completed)
--
Ivan Zhakov
Re: [serf-dev] Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, May 24, 2011 at 6:32 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> It's really hard reproduce problem, because it's related to timing of
> sending and receiving requests. From the code my feeling that issue is
> still exists, just in more complicated scenario with more requests but
> I didn't find reproduction script.
Can you give me an idea why you think the issue still exists? We'd be
adding the new priority requests after all of the previously-queued
(but unwritten) priority requests...so, unless I did a silly think-o,
I don't see why it would if the situation matches what was described
in the issue. -- justin
Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Wed, May 25, 2011 at 05:03, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Wed, May 18, 2011 at 10:38 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>> What is the "serf request ordering problem"? Never heard of any problems
>>> with that code.
>>> Lieven
>>>
>> I've filled issue 72 in serf issue tracker:
>> http://code.google.com/p/serf/issues/detail?id=72
>>
>> I'm not sure should I add an issue for that to Subversion issue tracker too.
>
> Thanks for the report - please see r1469. It should fix this issue. -- justin
>
It's really hard reproduce problem, because it's related to timing of
sending and receiving requests. From the code my feeling that issue is
still exists, just in more complicated scenario with more requests but
I didn't find reproduction script.
--
Ivan Zhakov
Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, May 18, 2011 at 10:38 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> What is the "serf request ordering problem"? Never heard of any problems
>> with that code.
>> Lieven
>>
> I've filled issue 72 in serf issue tracker:
> http://code.google.com/p/serf/issues/detail?id=72
>
> I'm not sure should I add an issue for that to Subversion issue tracker too.
Thanks for the report - please see r1469. It should fix this issue. -- justin
Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Thu, May 19, 2011 at 00:54, Lieven Govaerts <sv...@mobsol.be> wrote:
> On Wed, May 18, 2011 at 5:53 PM, <cm...@apache.org> wrote:
>
>> Author: cmpilato
>> Date: Wed May 18 15:53:04 2011
>> New Revision: 1124306
>>
>> URL: http://svn.apache.org/viewvc?rev=1124306&view=rev
>> Log:
>> * notes/berlin-11-agenda
>> Add my first-pass notes about the discussions we've had here in
>> Berlin. Others may wish to fill in more of the details as they
>> recall them.
>>
>> Modified:
>> subversion/trunk/notes/meetings/berlin-11-agenda
>>
>> Modified: subversion/trunk/notes/meetings/berlin-11-agenda
>> URL:
>> http://svn.apache.org/viewvc/subversion/trunk/notes/meetings/berlin-11-agenda?rev=1124306&r1=1124305&r2=1124306&view=diff
>>
>> ==============================================================================
>> --- subversion/trunk/notes/meetings/berlin-11-agenda (original)
>> +++ subversion/trunk/notes/meetings/berlin-11-agenda Wed May 18 15:53:04
>> 2011
>> @@ -5,12 +5,17 @@ discuss, and make themselves merry.
>>
>> [ should we include an expected attendee list? ]
>>
>> -Potential items for discussion:
>> +POTENTIAL ITEMS FOR DISCUSSION
>> +==============================
>> +
>> * Let's finish Subversion 1.7
>> + * Externals discussion
>> * ra_serf issues
>> - Should we leave serf as default http library?
>> - Checkout/update editor memory and performance issues. May be
>> it is worth implementing non-skelta update editor mode in ra_serf.
>> + - Serf request ordering problem when re-submitting for authn.
>>
>
> What is the "serf request ordering problem"? Never heard of any problems
> with that code.
> Lieven
>
I've filled issue 72 in serf issue tracker:
http://code.google.com/p/serf/issues/detail?id=72
I'm not sure should I add an issue for that to Subversion issue tracker too.
--
Ivan Zhakov
Re: svn commit: r1124306 - /subversion/trunk/notes/meetings/berlin-11-agenda
Posted by Lieven Govaerts <sv...@mobsol.be>.
On Wed, May 18, 2011 at 5:53 PM, <cm...@apache.org> wrote:
> Author: cmpilato
> Date: Wed May 18 15:53:04 2011
> New Revision: 1124306
>
> URL: http://svn.apache.org/viewvc?rev=1124306&view=rev
> Log:
> * notes/berlin-11-agenda
> Add my first-pass notes about the discussions we've had here in
> Berlin. Others may wish to fill in more of the details as they
> recall them.
>
> Modified:
> subversion/trunk/notes/meetings/berlin-11-agenda
>
> Modified: subversion/trunk/notes/meetings/berlin-11-agenda
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/notes/meetings/berlin-11-agenda?rev=1124306&r1=1124305&r2=1124306&view=diff
>
> ==============================================================================
> --- subversion/trunk/notes/meetings/berlin-11-agenda (original)
> +++ subversion/trunk/notes/meetings/berlin-11-agenda Wed May 18 15:53:04
> 2011
> @@ -5,12 +5,17 @@ discuss, and make themselves merry.
>
> [ should we include an expected attendee list? ]
>
> -Potential items for discussion:
> +POTENTIAL ITEMS FOR DISCUSSION
> +==============================
> +
> * Let's finish Subversion 1.7
> + * Externals discussion
> * ra_serf issues
> - Should we leave serf as default http library?
> - Checkout/update editor memory and performance issues. May be
> it is worth implementing non-skelta update editor mode in ra_serf.
> + - Serf request ordering problem when re-submitting for authn.
>
What is the "serf request ordering problem"? Never heard of any problems
with that code.
Lieven