                            -*- text -*-

During Q1 2010, my CollabNet colleagues and I (C. Michael Pilato)
invited select customers (deemed to be generally representative of our
vast Subversion customer base) to participate in one-on-one meetings
around the general topic of version control.  All of these customers
are Subversion users; some of them are using it alongside other
version control systems.  Customers were asked to share openly about
what is missing from their version control experience.  The persons or
teams that I spoke with were knowledgable enough to identify what
would constitute a "core Subversion feature" or "core Subversion fix",
so most of the responses were self-limited to complaints or
suggestions about Subversion itself.  Some folks took us up on the
offer to speak about their version control experience in general, so
we got some feedback that might be best evaluated by, for example, the
TortoiseSVN project or CollabNet internal Engineering staff.

In all, I met (via teleconference) with 11 customer teams, and
received additional feedback from others via email.  Customers
provided wishlists of various sizes -- from only a couple of items to
as many as 15 identified as important enough to draw attention to in
our meetings.  Some identified the relative priorities of their
wishlist items; some did not.  None were privy the requests that other
customers had made -- we wanted to first understand what was annoying
them enough to stay in foremost in their minds (and not "lead the
witness").  (We will revisit every one of these customers with an
aggregate list of requests so they can each take a pass at
prioritizing the lot of them.)

What follows here is a summary of what I learned in the process, plus
the aggregated list of wishlist items (post-processed to add some
additional organization to the thoughts shared).


GENERAL TAKEAWAYS
=================

Subversion remains the version control system of choice for the
enterprise.  There is grassroots pressure from the lower ranks to give
DVCS a spin, but it's almost universally the case that the love for
DVCS comes not because of the distributed model itself, but from some
of the secondary features and behaviors of those systems: better
performance of day-to-day operations, better merge handling, better
handling of renamed items, and support for offline commits.
Interestingly, Subversion is where it is today inside most of these
shops largely because of similar grassroots pressure in favor of
Subversion over closed-source systems over the past six years.  An
interesting difference, though, is that Subversion's model to date has
always been in line with the basic needs of the enterprise, offering
centralized storage, path-based authorization, and so on.  DVCS tools,
on the other hand, stand opposed (by their very design) to some of
those core requirements, much to the chagrin of managers and auditing
bodies alike.

Enterprises are united in the desire to see Subversion continue to
push beyond mere "best of open source version control systems" status
and into a dedicated courtship of the enterprise user base and
administrators.  Install bases of thousands of users across multiple
geographical locations beg for sheer power, user simplicity, and
administrative control.  Some items that were commonly cited along
these lines include the following:

   * Performance:  Make it faster.  Then make it faster again.

   * Enterprise-class authentication and authorization:  Subversion
     should be able to work with other services on the corporate
     network.  Single sign-on (SSO), LDAP, Kerberos, etc.

   * Server-side control of client-side behaviors:  Admins want to know
     that every Subversion user has the same configuration for simple
     things like auto-props rules, and want to be able to control
     things like our "store-plaintext-passwords" toggles remotely in a
     way that's not easily override-able.

   * Improved branching and merging: Everybody loves merge tracking
     and tree conflicts.  That is, when they don't hate it.
     Subversion should be smarter, and *must* learn to gracefully deal
     with renames.

I didn't meet a single angry customer.  Were some of them frustrated
by certain shortcomings in Subversion?  Certainly.  But many expressed
strong support for Subversion, even saying outright that they would
gladly suffer 2.0 migration pains if it meant getting these features
into their hands faster.


WISHLIST ITEMS
==============

Performance

   Client Performance

   * Faster checkouts
   * Faster history browsing (log, etc.)
   * Faster merging
   * Better performance with large binaries
   * Reuse authenticated sessions

   HTTP Performance

   * Better overall speed (close gap with svnserve)
   * Alleviate path-based authorization logic performance penalties
   * Fully support caching web proxies

Security

   * Server-governed enterprise password caching solution
   * Kerberos support
   * Support for LDAP groups with path-based permissioning
   * ACL support with more fine-grained operational control
   * Bug: Update pulling new file copied from unreadable branch fails

Server Features

   * Server-governed configuration (per repository)
   * Forward history tracing (for tree conflicts, repos browsing, etc.)

Distribution

   * First-class support for clustering
   * Open source multi-site solution
   * Bug: "Chunk delimiter was invalid" seen in svnsync of large commits
   * svnsync performance
   * Write-thru proxy support for svnserve

Client Features

   Sparse Checkouts

   * Search-based sparse working copy population
   * Sparsely populated tag when made from sparse working copy

   Externals Enhancements

   * File externals from foreign repository sources
   * Recursion into external working copies during commits
   * Tagging recursion into externals, tagging those as well
   * Stabilize peg revisions of external definitions when tagging
   * --ignore-externals flag should be sticky (and add --include-externals)
   * More robust single-file externals

   Obliterate

   * Remove path or path revision leaving auditing breadcrumbs
   * Archive older revisions (by date or size)

   Merging

   * More robust merging
   * --reintegration should tolerate sparse checkouts that aren't affected
   * Use common ancestor as part of the merge resolution process
   * First class citizenship for mergeinfo (revision- and path-level support)
   * Better handling of property merges (particularly svn:mergeinfo)
   * Support path-level merge traceability without adding heavy overhead
   * Make record-only merges support transitive merges
   * Support cyclic merging (multi-reintegrate support)
   * Support --changelist option on 'svn merge' (limit merge targets)
   * Avoid creating svn:mergeinfo when merging into a sparse working copy

   Tree Conflicts

   * Better user feedback -- what's the problem and how do they resolve it
   * Detect where a renamed target has been moved to
   * Track renames/moves better to support refactoring
   * Automatic resolution of tree conflicts with obvious resolution

   Miscellaneous

   * Offline commits
   * Timestamp versioning
   * Clearer error messages (not just HTTP details)
   * Earlier abort of commits where a lock is missing/stale
   * Warning when an update to past revision removes a file
   * Support for single file checkouts
   * Search mechanism (find files by name, property value, etc.)
   * Shared changelists
   * Optional text-bases
   * Support/emulate symbolic links on Windows
   * Better support of WebDAV mounts under Windows
   * Support directory locks (of the 'svn lock' variety)
   * Support at least one previous version of working copy formats
   * Add svn_load_dirs.pl functionality to 'svn import' operation
   * Show node origin information in 'svn info' output

Extra-Subversional Stuff

   * Keep "Version Control With Subversion" up-to-date
   * Better migration tools for VC systems other than CVS
   * Repository search mechanism
   * Documentation and tooling to help admins leverage Apache power features
   * Single source of info for what's new and hot in Subversion ecosystem
   * More powerful and featureful repository browser (show merges, etc.)
   * Better graphical 3-way-merge tools