[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

I love Subversion!

From: Brian Huddleston <brianh_at_huddleston.net>
Date: 2005-05-11 06:06:41 CEST

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
Received on Wed May 11 06:07:41 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.