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