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 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.