Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "Berlin2013" page has been changed by CMichaelPilato: https://wiki.apache.org/subversion/Berlin2013?action=diff&rev1=16&rev2=17 Comment: More of CMichaelPilato 's raw notes from today's talks. * Tracking and non-tracking links * User-requested issue fixes for 1.9: - * http://subversion.tigris.org/issues/show_bug.cgi?id=1256 (mtime preservation) + * http://subversion.tigris.org/issues/show_bug.cgi?id=1256 (mtime preservation) - * http://subversion.tigris.org/issues/show_bug.cgi?id=3457 (replication of locks with svnsync) + * http://subversion.tigris.org/issues/show_bug.cgi?id=3457 (replication of locks with svnsync) - * http://subversion.tigris.org/issues/show_bug.cgi?id=3750 (hotcopy of locks) + * http://subversion.tigris.org/issues/show_bug.cgi?id=3750 (hotcopy of locks) - * http://subversion.tigris.org/issues/show_bug.cgi?id=2662 (authz with wildcards) + * http://subversion.tigris.org/issues/show_bug.cgi?id=2662 (authz with wildcards) - + == Discussion Notes == === FS-NG === brane presented his ideas for a revamped filesystem logical implementation that theoretically solves many of our common-most filesystem woes: * [[attachment:metadata-tng.pdf|Metadata indexing and server-side links]] - - === Release Cycles === In general, attendees expressed interest in shorter, time-based release cycles. The sole reason stated for feature-driven releases was for the purpose of always showing demonstrable progress on our users' needs (for example, merge tracking), but we generally agreed that this is primarily a communications problem. @@ -110, +108 @@ === Pipelining the client === stefan2 was polling the attendees regarding the feasibility of introducing multi-threaded handling and pipelining into the Subversion client layer. While today Subversion is largely I/O-bound, the concern is that at some point, Subversion will instead be CPU-found. How will we progress past that point? + === User acceptance testing === + CollabNet, WANdisco, elego need to be taking advantage of customer connections earlier and more often. While users@ has traditionally been a support forum, we are missing the opportunity to get UAT of even not-yet-coded features by not contacting users@ with our ideas and plans. We talked about trying to ensure that our next issue tracker have a workflow engine that would remind us to do post-dev UAT, too. + + === Attracting developers === + stefan2 noted that, going forward, we can probably expect that our client user base will be increasingly more Windows-focused. Unfortunately, Windows is the platform on which building Subversion is hellishly complicated. Animated discussion followed about how to make it easier to build on Windows. Consensus was, to say the least, not achieved. + + But what about other developers? jcorvel points to the simplicity of git users to clone a project repository and get to work. Perhaps we should provide some kind of bootstrapping script for creating a local repository, import Subversion's code, make a working copy of the Subversion source code, etc. + + === C++HL leading to a consistent binding interface between languages? === + Attendees seemed to agree in general to this idea. + + We talked a bit about bindings compatibility promises. Most of us felt that the only bindings which see large-scale consumption are the JavaHL bindings. Realistically – and due to developer neglect – there is a break in compatibility every time we notice (too late) that some new interface lacked proper “swiggification”, so we didn't feel like compatibility in the Swig-built bindings was so very important. + + === JavaHL native implementation eventually replaced by C++HL? === + Sounds like a good idea, and we don't anticipate that deciding to do so would cause the C++ wrapper to be unnecessarily constrained by the need to maintain compatibility in the existing JavaHL API. +
