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.
