March 14, 2004

Subversion + TortoiseSVN = AWESOME SCM solution

Ok, so belay my last message about running Subversion along side of CVS. I don't need to. Subversion is working PERFECTLY.

I spent yesterday setting things up... and all I can say is OMG. I have never been so impressed with how quickly everything snapped together as it relates to developer tools.

TortoiseSVN has made all the difference. It is just amazing. It has such slick integration directly into explorer its not even funny. Here is a screen shot of one of my C# code trees checked out of my Subversion repository:

With shell extensions turned on it gives an awesome icon overlay to immediately tell me if a file is out of sync, needs to be checked in etc. As you can see in that shot, Dacl.cs has been altered and needs to be checked in. A simple right click on it and hit "Commit" will do that. Or I could step out a directory or two, and it will recursively find which files need to be checked in, and do it for me.

It uses SSH2 and tunnels nice and cleanly through just about everything. The only issue I still need to resolve is how to get the client to use my ssh keys so I don't have to enter my password on every action. It seems to prompt me twice each time I take an action, and thats a bit annoying at times. Apparently its just a config option to get the TortoiseSVNPlink ssh agent to work... I just haven't gotten around to figuring that out yet.

The Tortoise Merge and Diff utils work great. I have already used it last night to do some compares, and it "just worked" for me. I like it when I don't have to think and the tool does exactly what they are supposed to do without me having to fuss with it.

I am running Subversion in standalone server mode, and NOT through Apache. I prefer to use the rule of separation for such tasks and I was able to do that nicely, configuring it to work as an unprivileged user with no access except to the source code repo. Here are the steps I took to basically get things going on the Linux side of things (using Debian as my base):

  1. apt-get install subversion
  2. adduser svn
  3. mkdir /var/svn
  4. svnadmin create /var/svn (Creates the initial repository. I spent more time figuring out how to do that then anything else)
  5. chown -R svn.devteam /var/svn (devteam is my corporate developer group on the server)
  6. chmod 775 /var/svn
  7. cd /var/svn
  8. chmod g+w db (group needs write access to the repo)
  9. chmod g+w locks (group needs write access to the file locks)
  10. cd db
  11. chmod 440 * (no one outside of svn and the dev team should be touching these files anyways)
  12. cd ../locks
  13. chmod 440 * (no one outside of svn and the dev team should be touching these files anyways)
  14. su svn
  15. crontab -e
  16. When in crontab add this: @reboot svnserve -t -r /var/svn
  17. :x (or whatever your save and exit key sequence is)
  18. svnserve -t -r /var/svn (Need to start it for the first time, since it would seem silly to reboot at this point)
  19. exit
  20. vi /etc/password and change the shell from /bin/bash to /bin/false for the svn user

Thats it. At that point I have Subversion running as user svn, with the local repo stored in /var/svn, accessable using SSH tunneling for the development group.

To access it with TortoiseSVN I just do a checkout via a right click and then type: svn+ssh:// and go to town coding my Pinky and the Brain Mind Altering Operating System. (Better knowns as PATBMAOS, or Longhorn for short)

I still have to get used to how Subversion works, and I could have done a better job by reading their docs BEFORE importing all my code. I wish I would have known to use their format of repository/project/trunk, repository/project/branches and repository/project/tags for the dir structure. Not sure how that will muck up my branches and tags. Will have to wait and see.

So, end result? I would sum it up as:

  • I have a completely integrated SCM solution working on my Windows dev machine that...
  • ... has its client completely integrated into Explorer,
  • ... with the server working on our existing Linux architecture with very little resource overhead,
  • ... which tunnels over SSH,
  • ... works similar to CVS,
  • ... but doesn't leave file crud in my master sources like CVS,
  • ... can be easily sandboxed and does NOT require external servers (ie webservers, although it can if you want)
  • ... was extremely easy to learn to use, with almost no learning curve past normal SCM operations
  • ... cost me NOTHING for the software, and implimentation costs were less than an hour
If you look back at my original requirements it met every need except for direct access to Visual Studio. And I am ok with that. To be honest, I am HAPPIER with it working directly in Explorer. Since most of my code is driven through kernelmode development using the DDK, I would have had to use the client outside of Visual Studio most of the time anyways. By using the same explorer window for both my VS based code and my DDK based code, I have a seamless and exactly same process for any code I work on.

So there you have it. Subversion + TortoiseSVN = My SCM solution. And I am quite happy with how it turned out.

Posted by SilverStr at March 14, 2004 09:05 AM | TrackBack

Would you mind sharing your overlay icons? The screenshot shows that you're not using the default ones which TSVN installes.
If you send them to I'm sure they'll put them on their website for others to enjoy too.

Posted by: Steve at March 19, 2004 06:19 AM

Those are the overlay icons Ryan Harris created and are provided on the ftp site from TortoiseSVN. You can download them from:

Posted by: SilverStr at March 21, 2004 10:52 PM

I am confused, you couldnt run Apache under a non priveledged account?

Wasn't there a security exploit in the stand-alone svnserve?

I am trying to switch from cvs to svn at work, so far it is pretty tight.

Posted by: Jeff Gonzalez at June 23, 2004 11:53 AM

No you can run Apache in a non privileged account, typically something like "nobody" or "wwwdata". However, exposing it across webdav means that my source control permission sets have to reside in the same sets as controlled by webdav to work correctly, and are in the same process context. As you can see from the steps I have done, I have really tightened down the entire thing to the user context of "svn" and the group of "devteam". No one else can access anything... as intended. On top of that, it separates the web server with source control. Having it decoupled and sandboxed away from each other is just good infosec practice.

There has been exploits for cvs and svn as of late. Like a good boy not only have I kept up with the patches, the SVN server is only accessable across SSH, which is only accessable through authenticated and authorized connections. In other words.... its as tight as I can get it.

Posted by: SilverStr at June 23, 2004 12:09 PM

I use subversion and it's great. As long as it's running on a *nix platform. I tried to have a windows environment set up here and last i checked (bout 8 months ago) it was horribly unstable. It also didn't have any integration into VS.NET. I've heard there is a new svn plugin for it which is cool but I've already gone the way of VSS.

The thing I hated about it most is that it (Svn) would totally hose web files like pdf's and pictures.

I still use it at home but for enterprise accountability I still think it's slightly a ways off

Posted by: Jerrad Anderson at June 23, 2004 12:58 PM