I love Subversion!

[Brian Huddleston <br...@huddleston.net>]

Hey guys,

Just wanted to drop you a quick note about how incredibly cool Subversion 
is...  I think sometimes getting bogged down in the bug fixing, feature 
requests and roadmaps discussions that you can lose focus of what an 
incredibly *cool* tool Subversion is...

My background, we just recently converted over from a CVS repository.  I 
thought I would share with you some of my experiences as a way of saying 
thank you:

* I love directory and file renames! *

I am a big history freak.  One thing that always sucked about CVS was that 
it made refactoring so hard to do.  By and large I was able to bully people 
into telling me when they want to move something around so I could manually 
copy the RCS file, manually delete out the tags that no longer applied to 
the new location, etc (eugh...what a pain).  But all too frequently, joeblow 
would "move" something by cvs rm-ing it and cvs-adding it, thereby creating 
the impression that the five year old foo.java file was created yesterday in 
its entirety by joeblow.  Drove me nuts.  Just yesterday one of our devs 
took about four hours and did a "marketing" refactor, changing a bunch of 
our classes to match the terminology we actually use when talking about 
things.  I pull up the newly renamed file...there it is with all of its 
history intact.  It brings a tear to my eye. :-)

* I love atomic commits! *

Everything falls into nice comprehensible changesets.  It is *so* easy to 
see what's going on.  Let me give you an example.  For historical reasons 
our shop is really branch averse.  (We had some bad experiences with 
multiple versions of our product and trying to keep bug fixes synched 
between them...it was a mess...could've been done better but it left a bad 
taste in everyone's mouth.  That and it took a *long* time to create a new 
branch, but that's for another point.)

So...we released our latest version into production and told one of the devs 
he could check in his changes for a big new feature he was working on.

So about 20 minutes after that checkin we discovered a P1 defect in 
production and needed to do an emergency upgrade....oops...No problem in the 
new Subversion world.  I reversed merged to the rev right before the big 
check in.  We fixed the bug dashed out a new build and merged the old 
changes back.  Yes it is possible to do that trick with CVS if you've done 
the labeling properly, but a huge pain.  As it was, it was quick easy and we 
didn't have to get into a holy war about branching.

*I love cheap copies!*
We have a continuous build environment.  So we do a *lot* of tagging.  Under 
CVS it would take approximately 15-20 minutes to tag our source base.  Under 
subversion it takes about 30 seconds.

They're also wonderfully flexible.  I'm working on a set of scripts now that 
will let us do something similar to Source Integrity's workspaces. 
Subversion lets me branch and switch individual files, that combined with 
excellent support for mixed working copies and I have what I need to let 
developers commit early and often to the nice backed up repository and to 
work on long running disruptive projects without having to protect the 
trunk.  All with just a little scripting.  That's good stuff.

*I love binary deltas!*
This helps us in two ways.  One we have a fairly huge BuildTools module and 
a Design module with lots of really big photoshop files.  That was *painful* 
under CVS.

Also our updates are quite a bit faster.  We're able to do a svn update on 
*everything* including BuildTools in about 20% less time than it used to 
take to just do a cvs update on the text source files.

*I love parseable output!*
I don't know who put this as a design goal, but Bravo!  We have a fairly 
complicated SCM system that tied together CVS, Scarab, BuildForge, and 
various reporting, summary and status pages.  I dreaded porting it over to 
use SVN.  It took a *lot* of work to put together.

Apparently you guys had that use case in mind.  Everything was immently 
query-able (I love query-able repositories!) and the results of all those 
nice queries was regularized.  No playing super-special regex magic to get 
the information I needed.

I had budgeted two weeks to get everything up and working.  As it turned out 
since there was an svnlook or svn command for *everything* I needed to do, 
and the since the output was in a nice sensible format, it turned into a 
weekend project tacked onto the end of the cvs2svn run.

The documentation is also extremely well done.  I have had next to no 
developer support to do thanks to the excellent svn book.

On the admin side, svnserve worked out of the box.  (We were using cvs and 
ssh previously, so everything Just Worked).

I put off playing with mod_dav_svn as I had got the impression that it was 
going to be unreasonably complicated to setup.  In point of fact it only 
took about 20 minutes.  Installed the rpm, edited the conf.d/subversion.conf 
to point to the repository, pasted in my mod_auth_pam directives and voila. 
I could commit via https and it knew it was me.  I now have an option for 
for those *cough* less technical types for whom I have no hope of walking 
through creating a dsa public/private key pair with cygwin.

Then there are all those cool mod_dav_svn tricks like web folders and 
autoversioning.  (I demo'd that today.)  Even the nice clean repository 
browser (the GET handler).  We're able to simply link to svn versioned 
images/mockups/documents in our  wiki now.  (It was easy to explain, just 
point to the same URL you see in TortoiseSVN).

Our CTO used the mod_dav_svn browser feature while in Europe to download the 
latest mockup from our design guy to his PDA phone.  That's just cool.  :-)

Anyway, I hope everyone involved will take a moment to pat themselves on the 
back for creating an extremely powerful, extremely useful tool.

I'll now go back to my default whining about new features I want, but I 
thought you guys might enjoy hearing my experience with it.

-Brian


 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org