Hello everyone -
Disclaimer: please do not consider this message a rant but rather a hopefully
constructive criticism based on personal experience with SVN.
Below is a description of a recent attempt to introduce Subversion as a viable
SCM solution for our company with an attempt to analyze the reasons for this
failure.
The task was to enhance the SCM process for an in-house library that is
currently maintained using RCS. The new process was supposed to rely rather
heavily on branching to allow developers to introduce changes to both
production version of the product, beta version and the current development
version. This process is failry tool-neutral so I won't go into the details.
The original RCS repository is comprised of about 300 ,v files all about 40Mb
in size. Files have on the average about 20 revisions with a very large
number of tags.
The SVN machine was a fairly new desktop box (p4-2.8, 512Mb RAM) running
Fedora Core Development w/ Subversion 1.0.0 (supplied by Fedora).
The very first showstopper was the import. Cvs2svn import process for the
repository to a local SVN repository has been running for 4 (sic!) days after
which period it was mercilessly put to death. By the kill time, the target
SVN repository grew to 1.8Gb (again, coming from 40Mb), of which about 1.5Gb
was taken by a single 'strings' DB.
The second annoyance was the fact that SVN effectively mandates the user
performing the merge to explicitly specify two revisions, the diff between
which would be applied to the target revision. While merge is no trivial
operation by any means, having a number of usable strategies implemented
would definitely help. In this particular case, at least having an ability to
merge the changes from another branch using common ancestor as a starting
point would help. Or, having a symbolic name for a revision number from which
the named branch was derived (e.g. /fooproject/branches/mychanges@BIRTH)
would also help. True, this could be all scripted on top of SVN but that
would be complex and error-prone.
Finally, there was also an issue of exaggerated expectations. For example, a
very large number of CVS users I had to deal with were confident that
Subversion would track merge operations. I heard numerous times "Well, if
Subversion doesn't track merges, it is basically a CVS with a DB and atomic
commits."
Analysis of the experience:
1. Import process seems to be absolutely inadequate. I don't even want to
estimate how much time it would take for the entire body of our source code
(about 35 Mil. LOC). Unless it is a clear bug, fixing which would make the
process several orders of magnitude faster (ClearCase import from CVS for the
same code takes about 45 minutes) I am not sure it is usable.
2. Repository size seems to be too big. 40Mb of RCS data resulted in 1.8Gb of
SVN data. Even more troubling is the fact that most of that bloat went into
the single file (strings). Having a single file that big is always a problem
as the IO may deteriorate and the O/S may show some weird issues when dealing
with large files. Also, I am not sure how well BDB will scale for databases
that large. I am afraid to think how big this file would be for our entire
source code ;-) ClearCase has learned it over the time so now they have
guidelines for splitting the source code across multiple VOBs.
3. Another troubling thought is the one about tags. As I said, we had a lot of
tags (about 150 per file). I wonder it was the tags that resulted in all that
bloat, then something is wrong with the implementation of lazy
tagging/branching.
3. Merging needs some enhancements
Immediate lack of ability to merge the entire branch into the current revision
makes it very painful to handle merging and in fact it actually makes SVN
*worse* than CVS for merging. Again, it is difficult to implement merge
operation to work right in most cases but having some logic to make it work
on par with at least CVS would definitely be a great step forward. Also,
having merge history, while non-trivial, is definitely required to claim any
advancement over CVS.
Anyway, we are now moving the project to CVS. I am still an avid SVN user at
home but it will take some time before we try using it at work. ;-)
Regards,
--
Alexander L. Belikoff GPG f/pr: 0D58 A804 1AB1 4CD8 8DA9
Bloomberg L.P. 424B A86E CD0D 8424 2701
abel *at* vallinor4 *dot* com (http://pgp5.ai.mit.edu for the key)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 20 22:40:59 2004