The Berlin '11 hackathon will be held at the elego offices in Berlin, Germany on May 16-20. elego has generously donated office space and $BEVERAGE for the duration of the week, and several committers will be on hand to hack, discuss, and make themselves merry. [ should we include an expected attendee list? ] 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. - What is a reasonable long-term performance goal for SVN? * 'svn resolve --accept {mine,theirs}-full' for tree conflicts - Now that update skips no tree conflicts, we have a fighting chance. * Python test timing - Identify slow tests - Sort tests into short- and long-running sets, for convenience. * Making blame faster (1.8+ probably) - Implementing reverse blame - Making diff faster (see notes/diff-optimizations.txt) - Calculating blame info on server side? - Caching/saving changed-line-info on server side? * [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 propagating 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.