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 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. :-)
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.
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.
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 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 (dev mailing list 11 May 2005)