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.