Note from user visits by Hyrum - Jan., Feb. 2010 Introduction ============ I've recently had an opportunity to visit with a number of corporate users of Subversion. My basic question was "what should you think the future of Subversion should be?" While not everybody spoke to that question, all the responses were illuminating, so I'm recording them here for posterity. (These aren't all of the people I've talked to, just the ones which had the most feedback.) User 1 ====== Background ---------- A large corporate installation of Subversion. The development manager I spoke with supervises several thousand developers. They use Subversion, but there is some grassroots movement from his developers to switch to a DVCS. Concerns -------- Branching & merging too slow Overall speed "Branching & merging fixed by the end of the year, or you are dead." Refactoring support "If you are going to fail, I'll leave as soon as possible." Great interest in obliterate support Places Subversion stands out ---------------------------- Multi-platform support (others) Take-aways ---------- Overall, the meeting was a bit negative, but that's what I expected (and asked for, even). Hearing folks' concerns is how we improve. In the end, I came to the realization that we wouldn't be having the conversation if folk like him didn't see hope, and didn't want to see improvement. As a development manager, the idea of moving to a DVCS is not very appealing at all, and he wants to see Subversion succeed. User 2 ====== Background ---------- Another large corporate installation, recently moved from CVS to Subversion. ~3000 developers. Concerns -------- Obliterate support Tags are useless (would essentially like revnum aliases of some kind) No zero-change commit support. Long option names Atomic import (a delete and import in one rev) Merge ancestry issues are painful Want 'svn diff@WORKING' Various scalability concerns Long-running merge operations Places Subversion stands out ---------------------------- Much better than CVS in every practical way Take-aways ---------- A lot of the Concerns are actually somewhat-valid feature requests. We should attempt to vet them, and if found justifiable, implement them. User 3 ====== Background ---------- Large multinational corporate, many regions each with relatively few developers (10-20 per region say), couple of hundred in HQ. Beginning to work with outsourced development centres. Moved from VSS to SVN 18 months ago (but planning longer). Concerns -------- * Performance. Base product is 20,000 files in a few hundred Mb Data, plus smaller modules. Initial checkin of the base often fails and has to be performed piecemeal. Some log commands take a while, TortoiseSVN's revision graph is unusable. * Server-based configuration. It's not nice when a user forgets to set his global-excludes for example. * Obliterate support would be nice to clean up the repo. * Archiving support also - ie to delete revisions over 2 years old, for example, whilst keeping newer revisions. * Better admin tools in general, our repo is 12Gb now, so svnadmin dump/filter/load is almost impractical. * Tags are useless (almost), we'd want revnum aliases too. Especially would like to create a single tag, but then use that to hold all releases - eg, 1 tag branch where each revision is a release. Merging makes this slightly difficult and not suitable as we just want to 'merge' onto the tag by copying the current file over, not by merging revisions, not by doing a checkout and commit. * Search - there's no good ability that can index a repo for searching, nor to search log comments. Places Subversions stands out ----------------------------- * Simple and easy to use. * Good repository view - the directory structure is easy to understand and has good visibility. * Excellent integration with other tools. "right thing done right" when combined with other best-of-breed tools can be beautiful (eg bugtracker, requirements/project management, document repositories), plus other utilities such as TortoiseSVN and Apache views. * Svnsync. Other Users =========== I talked to one user who had actually written a custom client, which allowed them to implement overlay checkouts, which was important for their work flow. I was duly impressed, in a sort of "what-in-the-world?" way. A chip design firm is interested in using Subversion to version their artifacts, and was interested to know what kinds of integration exist for the various chip design tools.