-
Jason D. Lee of Hobby Lobby
(15 Dec 2004)
I work for a large retailer in the US. We are currently
going through a certification process with VISA. Part of the
compliance demands are that we track all router and switch
configuration changes, noting what changes were made and who
made them. We had a vendor come in and demo a very complicated
system that did the job, but was priced at around $80,000. Even
in the middle of a $1M+ project, that's a lot of money. When
one of the network administrators told me what the price tag
was, I immediately pointed him at Subversion. A few days later
of testing and developing methodology, we now have the router
configs for our 300+ stores as well as our corporate routers
safely stored and tracked in Subversion. Our network
administrators use TortoiseSVN for all of the commits, and those
with access can view the history using WebSVN, and all this cost
us one 1U server, which was reclaimed from a decommissioned
server cluster. It has been fast, stable and easy to use.
Here's a big thank you to the entire Subversion team, especially
the ones who tireless answer questions on IRC. You have built
an amazing system that I recommend every chance I get.
Jason Lee
Programmer/Analyst
Hobby Lobby Stores, Inc.
-
Ron Bieber
(23 July 2004)
I currently manage a group of about 20 developers for a
Fortune 500 company. We used CVS from January of 2001 until May
of 2004 when we converted all of our repositories over to
Subversion.
The advantages we received from Subversion are immense.
Before our conversion to CVS from VSS, we had two full time
employees managing our production builds. Upon conversion to
CVS we cut that resource count down to one. This resource
handled all branching and merging activities, reporting
activities, and manipulation of the CVS repository to move files
while retaining history. The CVS branching and merging was just
too cryptic (and took too long) for anyone to want to learn it.
We had two CVS "experts" in house which included me and one of
my direct reports. We were constantly called in to resolve
issues. I myself spent a ton of time managing the support of
the CVS repositories.
After running across Subversion by chance in May of 2003,
I started piloting it at home. As I used it more, I became
convinced that this was a tool that my team needed in order to
increase our productivity. After using it for a while, I was
able to come up with some specific areas that justified our
conversion to Subversion in order to maximize our productivity
and code quality:
- Atomic commits - The lack of atomicity in commits was a
huge problem for us with CVS. Subversion gives us the
confidence that when we commit, everything went into the
repository.
- The ability to back out changes before going to
production--using an activity branching model, we can allow
developers to branch per activity and only merge to the main
source base after code reviews have been performed. If there
are problems, we have one revision we can back out that
includes the full changeset for that change. While the
repository level revisioning was a shift for my developers to
make that didn't happen immediately, it begins to make sense
when an activity had to be removed from the build. In CVS we
had to go through each file looking for revisions that were
effected by a change. Subversion now manages this for
us.
- Decreased build time. We run CruiseControl, and the
checkout times we were experiencing with CVS, along with our
requirement to tag of our source base after each build caused
our automated build cycle to take an inordinate amount of
time. With the restriction that all production changes MUST
go through the build, this made emergency situations very
stressful. The cheap copy functionality of Subversion
decreased the time it took to get a change into source
control, through the build system, and into deployment
packages by 80%, greatly increasing our response time.
- Directory Versioning - this was a big deal that caused us
to actually evaluate Clearcase at one point. The CVS Attic
was killing us in checkout time and build time with the
velocity of change we were making to the source base. When
checkout times got too slow, we would have to wipe out the
attic, effectively wiping out the history of our source base.
With Subversion, we can remove something from the repository
and not suffer performance penalties later (and still be able
to get the deleted contents back).
- Simpler (and faster) branching - we no longer have a full
time FTE managing branches. We are now cycling this activity
through the group. Each developer can perform this activity,
because it is now part of his daily work.
As a manager, converting to Subversion was one of the best
decisions I have made thus far that had a such a direct and
highly visible impact on the productivity of my team.
I hope this helps you make your case for Subversion. My
personal opinion is that no one should even consider CVS at this
point in time. Subversion is a great product and the support
you get just on the mailing lists alone (from the development
team no less!) is second to none.
-
Ross Mark of Controlling Edge Inc
(22 July 2004)
For my own company Controlling Edge and at one of my
customers S4 Technology (www.s4-technology.com) I have been
running Subversion since 0.17 and have never looked back. While
there were a few issues initially we have never lost anything
and currently have around 20 repositories containing everything
from source code, documentation to complete product
installations. We use Subversion to install and upgrade the
software on our servers. Once we copy the svn client onto the
box the entire installation is a simple svn co plus the asvn to
restore symlinks, devices and file permissions. Upgrading
between releases with svn is great as it automatically merges
any changes to local configuration files with new entries for
the latest version. We even use svn to store file system images
for our embedded devices (linux file system). Currently we have
to check out the svn image on a server and then downloaded to
our embedded device via rsync. We don't have the memory for a
full svn client nor the disk space for the working copy but one
day we will write our own svn client that can just do the
checkout without the need for the wc support files or the memory
overhead.
For the past 9 years I had been installing CVS at
customer sites that required version control and wouldn't
hesitate now to recommend SVN instead.
-
John Szakmeister
(21 July 2004)
I work for a government contracting facility. We develop
everything from hardware, to full-fledged software applications,
all of which supports mission-critical activities. We're
currently using it on one of our most productive teams, and
houses about 3 years worth of work (for about 14 developers).
We started off with CVS, and found that the customer was
constantly coming back with request for features and upgrades.
Our small test projects would turn into fully-funded
applications, and as such, we had to restructure them. It was
just too painful with CVS, and we decided to look for something
better.
We found Subversion when it was at version 0.17. We
started with just a few developers using it, and then migrated
our other developers over time. I can say without question that
it has been one of the best decisions that we've made.
Subversion works better than CVS ever did. We can detect
corruption before it gets to be a problem, we get atomic
commits, and directory versioning. All of which has made our
development process and our ability to adapt to the customers'
ever-changing requirements that much easier. Plus, it natively
supports both the Windows and Linux platforms (versus the mixing
of CVS and CVSNT that we had before), which is our primary
development platforms. We've never lost any data, and our
developers have found it to be a very intuitive tool.
Subversion has been rock-solid in our environment, and very much
complements our software engineering practices. I can't speak
highly enough of it.
-
Stuart Robertson of Absolute Systems, Inc
(5 May 2004)
I introduced SVN to Absolute Systems Inc.
(www.absolutesys.com) where I work about a year ago, and for
about 8 months we ran internal SVN pilots, played around to gain
experience and trust, etc.
In the last 4 months we have migrated all of our internal
product source repositories from Visual Source-Safe to SVN using
an internally-written VSS-to-SVN migration tool.
Our largest SVN repository is now 3.7GB and currently has
68806 revisions. We are running SVN 1.0.1 + Apache 2.0.48 on
Linux. ...
SVN is a superb piece of work, and it is a *huge* step
forward from VSS. To put things in perspective... previously we
had 26 VSS databases for one product, primarily because of
problems with VSS when the repositories grow large. As you can
imagine, trying to manage product releases across so many
repositories was really painful.
Now, with SVN, *all* of the artifacts for that same product are
in a single repository, meaning that with a few cheap copy
operations all of the sources that make up a given release can
be grouped together. ...
-
Gustavo Niemeyer of Conectiva Linux
(25 February 2004)
I'm sure you are aware about the fantastic product you
people have built, but I'd like to tell you a little story which
should give new users some comfort about it.
Here in Conectiva we used to maintain our packages in a file
based system, storing the latest SRPM packages, and also some
old versions in case something bad happened. For a long time we
wanted to build some system which would make our life easier in
the daily work, and at the same time would give us some
flexibility accessing historic information.
Shortening the history a lot, 1 year and 6 months ago, the
first revision was committed into our repository:
% svn log https://svn.distro.conectiva/repos/cnc -r 1
------------------------------------------------------------------------
r1 | niemeyer | 2002-08-27 17:12:04 -0300 (Tue, 27 Aug 2002) | 1 line
Created basic structure.
------------------------------------------------------------------------
Since then, 5 complete Conectiva Linux distributions were
committed into the repository, and every single update in the
distribution is done using Subversion. We've already surpassed
50000 revisions, in a 30GB repository. Even though we have had
space, memory, and other kinds of problems around the
repository, I'm proud to say we have never lost a single bit of
information since then.
Based on this, the least I could do is sending a big THANK
YOU for everyone involved in the project.
-
Mark Bohlman of Teledata Communications
(21 July 2004)
Teledata Communications has been using Subversion for
storing all of the source code on all our software products for
the past year (since version 0.24). I have been very happy with
the overall results and they way that developer impacts are
minimal. We have not lost a single byte of code nor had any
significant issues with using Subversion since the beginning. I
attribute part of the productivity gains we have see in the past
year to the move away from our prior system with locking (and
the corresponding messages back and for to have something
'unlocked'). We continued to expand the use of the product to
all groups in the company.
Mark Bohlman
Software Development Manager
-
Mark Grosberg, regarding Assenmacher Specialty Tools
and GladeSoft
(21 July 2004)
AST makes automotive scan tools. We keep our source code
for both the embedded side and the Windows interface side under
Subversion. In addition we keep our (large) databases under
Subversion as well.
GladeSoft sells an embedded webserver toolkit and
application framework. Subversion stores all of our code and
documentation. In addition we store all of our business records
in Subversion; so I guess we can't pull an Enron as easily
:-)
Neither company has lost a single change with
Subversion. Both companies also have satellite workers who use
SSL to access the source repositories. Subversion
administration is relatively straightforward provided you use
Apache so there are no permission problems. At AST most of the
server administration is done by one of the mechanics who has
other work to do.
-
Fog Creek Software on the
FogBugz and TortoiseSVN integration
Fog Creek Software has been using Subversion as our
source control system for a few years now. We switched awhile
back from using CVS and have nothing but praise for Subversion.
Anyone currently using CVS should bite the bullet and make the
switch. It just works. The price is right, and best of all it
integrates tightly with FogBugz. We support a whole host of
Source Control Systems, and adding new ones is very simple,
but if you are starting out -- our recommendation is to start
with Subversion.
Once you get Subversion set up and running, if you are on
Windows, you will be amazed at how useful a good Subversion
client can be. Steve King has created a fantastic piece of
software, the TortoiseSVN client, and he has spent some time making sure
that it works perfectly with FogBugz. [...]
-
Robert Zeh of Error Free Software
(23 July 2004)
I manage a 13 member application development group for a
trading firm. There are about 9 other developers outside the
group, and some others, so we have about 20 people using our
Subversion repository.
For the past 10 years we used SCCS. It was very
frustrating --- files could not be renamed or moved, developers
would forget about locks they had acquired, and remote
development was next to impossible. SCCS also made our limited
Windows development painful (we are a Unix shop).
Since we switched to Subversion things have been much
better. Our entire history was transported into our Subversion
repository, so none of our history was lost. I wrote a Python
script to transform it directly from SCCS to Subversion, and it
was painless.
Conflicts have been very rare. The ability to easily
branch has been very useful; developers can make commits to
branches without breaking other people's code. It's easier to
see what people are working on as the commits hit our internal
commit mailing list. Since we tag each release, we're able to
determine which source code contributed to a release.
TortiseSVN makes Windows development easy (no more ftping files
over, or trying to build on a remotely mounted samba
drive).
Robert Zeh
Manager, Application Development
Error Free Software
-
Chris Wein of Mobilygen
(23 July 2004)
I also have had a very positive experience moving from
CVS to Subversion in a commercial setting. We are a small-ish
silicon valley startup that used to have everything in CVS.
Shortly after I joined as s/w manager I switched the s/w team to
SVN (0.37) with excellent results. We have had zero loss of
data, zero down time, with effective branching, easy repository
restructuring and constant time tags as our big positives. The
entire company will be moving in the near-ish future based on
our pilot. And of course the support from this list is
fantastic.
[Fair play dictates that we also
include the wish-list portion of Chris's
testimonial...]
As for my wishlist, it is short - completely seamless and
foolproof tracking of merge history at the same level as the
commercial tools. I don't want to remember revision numbers, I
just want to branch and merge with the tool remembering common
base versions etc. This is really the only thing I miss about
ClearCase.
[We agree :-). Better merge tracking
is on Subversion's long-term roadmap.]
-
Martin Pittenauer of SubEthaEdit
(2 June 2004)
We are using Subversion since version 0.17 and it never
let us down. On contrary it provided a much better experience
than any versioning system we have used before, including CVS
and perforce. With Apple adding support for .svn files within
NIBs with Xcode 1.2 we are certain that Subversion is the ideal
versioning platform for modern software development on Mac OS
X.
