It's been a few months (rapidly approaching a year) since our migration
from SourceOffSite + Visual SourceSafe over to TSVN+SVN. I can't speak
to a formal development process because ours is a very small shop and we
use SVN (and VSS) for more then just code warrior work.
Things we like:
- Efficient storage of binaries (such as MS Word, Excel or Access
files). Checking in a 200MB Access database in VSS was a pain, even
compressed it was still around 20MB over the WAN link. With SVN, only
the changed parts get transmitted. That might only be 1-2MB of traffic.
- Ongoing development work thanks to the SVN team.
- Pay for support, rather then paying license fees. One less batch of
licenses that have to be tracked, audited, stapled, and spindled. If we
add a developer or another user, there's no software cost or management
time needed to procure more licenses.
- Secure communication using SSH public keys over the WAN. We don't
even have to VPN in first.
- Cross-platform tool. In case we ever move from Windows to Linux for
the desktops. We considered moving to SourceOffSite's next tool, but it
would have required a substantial investment (SQL Server + license
fees). And SOS didn't offer a solution for the Mac folks that we have.
- Command line tools that work in conjunction with TortoiseSVN. In
order to stay in sync with each other easily, most of us use a batch
file that does an "svn up" on our job tree when we first log in.
Things that took getting used to:
- No sharing of files between folders (svn:externals does not do it,
yet...). For our website, we'd often have an index.asp file that was
common among multiple URLs and VSS gave us a way to share that across
those URLs. We now use an index.asp file that consists of nothing more
then a single #INCLUDE. But there are other cases like that where
sharing would be nice. We made extensive use of it in VSS and are still
getting used to not having that feature.
- It was a lot easier with SOS+VSS to bring down just part of a
repository tree. VSS/SOS would simply create a local folder in the
proper place, allowing you to bring things down quickly. We got used to
the VSS way of doing things (every developer has a folder called
C:\Company, and files are always in the same spot across all machines as
a result). This is more important for those of us who use SVN as a
distributed file system for non-development work. All of our project
files (documents, images, databases, web files for a particular URL) are
stored in SVN, because the majority of us work offsite 90% of the time.
SVN allows us all to have (or get the latest) quickly. But VSS was
easier about letting us only download the parts we needed now, with
quick access to other portions of the repository later. (SVN's sparse
working copies may fix that down the road.)
- In follow-up to the above, due to lack of sparse support and not
wanting to create a zillion working copies on the local machines (making
it harder to keep track of). We had to boost the disk space on our
machines to allow pulling down the entire job repository. Since we each
work on close to a dozen jobs per month, plus possibly looking at
another dozen jobs, this saves us setup time for creating those dozens
of working copies on our hard drives each month. It also makes it
easier to call a co-worker and have them look at something (it will
already be on their hard drive). One fix that we haven't implemented
yet would be to use WebDAV to allow quick access to files that we
haven't yet downloaded locally.
- VSS uses slightly different terminology then SVN. We've adjusted to
the new working style where you don't checkout files before changing them.
Things that I'm still not completely happy about:
- Storing a 50 MB video (or other uncompressible file) in SVN requires
100 MB in the local working copy. This is because SVN keeps a pristine
copy of the last committed version in the _svn/.svn folders. It's a
design decision that I understand why they did it that way, but some
days I wish I had more space on my laptop's hard drive.
- At the time, VSS2SVN scripts did not work for us. So we simply froze
the VSS/SOS repository (making it read-only), then started over from
scratch in SVN with the latest versions from VSS/SOS. Fortunately for
us, we're packrats and I have yet to need to go back to VSS because
everything we needed was still in the latest version of the repository.
...
Sorry that was so long, but it was not a completely painless switch.
Plus, I've been thinking about some of these issues the past week and am
looking forward to v1.5 and v1.6 of SVN.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 11 16:14:29 2007