Setting up svn in Apache is more complicated, especially under Windows. Still a great article! :)

Have you tried any distributed source control? I've recently switched from Subversion to Mercurial, and I'm very happy about the change.

The most important reason was the ability to clone the repository to my laptop, do some checkins there (without network access, on a plain, train, etc.) and resync with just one command when I'm back home. Distributed model seems cool even for a single developer :)

Also I don't like the way Subversion deals with branches and tags (i.e. by "cheap copy"). It simply doesn't work well for me, e.g. if one checkouts a repository with many tagged and branched versions, the workspace becomes much bigger than it should be. To avoid it, one needs to selectively checkout parts of the repository, I find it quite annoying.

Has anyone tried any of the Visual Studio.net plugins for Subversion?

@Tim Almond

I use AnkSVN. It works great as a simple indicator of changed files within the IDE, but it seems bit clunky to actually use beyond the Diff and Add commands, IMHO.

I stick to TortoiseSVN for all other needs.

Local System account is actually not a limited account. It has EXTREMLY high access to your local machine, but no access across the network.

> Setting up svn in Apache is more complicated,

What does that get us? Some kind of web UI? Use of port 80?

> clone the repository to my laptop, do some checkins there (without network access, on a plain, train, etc.) and resync with just one command when I'm back home.

What is the difference between what you describe, and working traditionally offline, then checking in when you get back into the office? If a "checkin" occurs on your local machine, and nobody else in the world knows about it.. did it really happen? Maybe I'm not understanding the distinction here. I still need to watch the rest of Linus Torvalds' presentation on this topic ( http://www.youtube.com/watch?v=4XpnKHJAok8 )

> Also I don't like the way Subversion deals with branches and tags

True, that part is a little ghetto-- you shouldn't be able to check a change into a "tag", but you can. The tag is sort of an illusion-cum-convention in Subversion; it's really a branch.

There is no perf penalty for creating hundreds of branches, though. They're only ultra-lightweight pointers until a change occurs under that branch.

> Has anyone tried any of the Visual Studio.net plugins for Subversion?

No, I haven't. But there are two that I know of:

http://ankhsvn.open.collab.net/
http://www.visualsvn.com/

This is sort of a religious issue. Some developers believe source control should *never* be done inside the IDE, and I've started to see their point after dealing with the many, many bugs in the Team Explorer Visual Studio integration point of Team System.

@Tim:

We looked into SVN plugins when we moved to SubVersion last year, and after trying a few we found VisualSVN (http://www.visualsvn.com/) to be the clear winner - VERY nice integration with Solution Explorer, and context menus to quickly find out a current file's history, or diff between two versions, etc.

It may be a little pricey for some at $49 a seat, but I definitely think it's worth the money. Hope that helps :o)

>> clone the repository to my laptop, do some checkins there (without network access, on a plain, train, etc.) and resync with just one command when I'm back home.

>What is the difference between what you describe, and working traditionally offline, then checking in when you get back into the office? If a "checkin" occurs on your local machine, and nobody else in the world knows about it.. did it really happen?

The difference is that you can keep a trace of the different checkins you did and you can go back when you want on your local repository. And then you can checkin to the main repository in the end.

>> Setting up svn in Apache is more complicated,
> What does that get us? Some kind of web UI? Use of port 80?

Well, it can get you per-directory permissions, a web UI (to browse at least) and a few other things. I've got it setup on our Linux server, and it hosts to (mostly) Windows clients.

Ankh is nice, but somehow it feels rather clunky. I stick to Tortoise, or the command line for anything substantial. On Linux, I use either kdesvn or the command line.

I'd still like to switch to a distributed VCS if only for my own convenience, but too many people don't even grok basic branching and tagging... It'd be torture on them.

http://svn1clicksetup.tigris.org/ <- 1clicksetup, all i need for my svn happiness, server+client

What sold me on subversion was using an editor like e ( http://e-texteditor.com/ ), where TortoiseSVN was seamlessly integrated in the project view. Really makes a huge difference in the daily workflow.

> What is the difference between what you describe, and working traditionally offline,
> then checking in when you get back into the office?

I think this comes down to your philosophy if when to commit your code. Personally I like to make fairly small, incremental changes. I find that this helps when you make a mistake and need to back-track and, more importantly, when you need to merge into another branch.

With subversion you can't really do this without having your own local repository in addition to the central one. This gets messy.

Great tutorial !

could you do the same tutorial for installing and configuring trac on windows...

>What does that get us? Some kind of web UI? Use of port 80?

Many organisations don't allow to open any ports except for the standard 80, 443, etc.
And screw web UI, we've got Trac for that :)

http://www.visualsvn.com/server/ <- simple setup for svn + apache and it's sweet

We've used Subversion for nearly four years and are on the whole very happy with it (~16 developers, plus QA, plus other groups using it for non-source code files). The biggest limitation we've hit is the rather poor tooling related to merges, though it seems svn 1.5 will have considerable improvements here.

We found setting up the repository to use Apache as the server indispensable to permit browsing of checked in files. We don't use this as much for source code as for other documents (specs, certain test data, etc.). It makes for easy integration to wiki pages, for example, and also makes it easy to for people to "check out" (peruse) specific directories/files (e.g. spreadsheets, Word docs) without _checking them out_. If the repository purely serviced development needs we likely wouldn't leverage this as much, though I've found it useful to quickly look at code in branches/tagged versions that I don't have active in my workspace.

Most of our development is in Java and we make use of the Subclipse Eclipse plug-in, though I personally just prefer to handle svn tasks outside the IDE. We also have used Ankh for our VStudio/C++ work and it seemed to work reasonably well.

Although we don't have a distributed development team, an advantage I can imagine to distributed version control, where needed, is actual revision support locally. If I were doing substantive development work without more or less constant access to the repository I would want something more than the file system and the IDE's "local history" feature for revision control. This is a key difference I see between just "working offline" and having revision control support locally. Linus pitches this as one of the chief requirements a distributed revision control system is meant to address.

Clearly the needs of a large and largely uncontrolled distributed project are quite different than the needs of traditionally managed teams ("uncontrolled" in the sense that anyone can join and start tinkering, even if official versions go back through some approval process). Linus claims that until he used BitKeeper he didn't even believe that revision control was necessary or useful, which I find quite revealing either about how he likes to work or the type of work he's done or both.

I always thought that "SYSTEM" is the *most* powerful account...

I agree, http://svn1clicksetup.tigris.org/ is a great way to get started with SVN.

Alternatives for a Windows subversion-server:
* http://www.assembla.com/ Web hosted workspace with SVN, wiki (TRAC), chat, and much more (free for personal use)
* http://buildix.thoughtworks.com/ Live-cd or ubuntu-install with SVN, project management, Cruise Control for continuous integration and TRAC as a wiki and bug-tracker

As clients I recommend TortoiseSVN or the well done subclipse plugin for Eclipse (http://subclipse.tigris.org/).

> Setting up SVN in Apache is more complicated,
>> What does that get us? Some kind of web UI? Use of port 80?

Yes, with the apache integration you are able to browse your repository with a web interface. FishEye (http://www.atlassian.com/software/fisheye/) is another great (but commercial) web UI for CVS and SVN. TRAC (as mentioned above) also has a integrated repository browser.

A lot of Svn users are moving to Git. I haven't tried it myself, but I thought I'd mention it, since this is the first blog posting I've read in a long time promoting the old hotness ;-)

by the way, is it just me or does your CAPTCHA always display the word "orange"?

Jeff, I agree with you about distributed source control that it is not easy to see the difference with centralized source control. I tried Mercurial for some time and had the same issues.

Actually, this if often a misunderstanding of what a source control system is. I think all programmers will agree with me that source control system allows:
- to work on a common source code ;
- to keep an history of the changes ;
- to back up your work.

The order I choose is intentionnal, this is the way people understand source control. First I can share with others, then I save history, and then I feel safe because my code base lives in a secured server.

With distributed source control, the goal is primarily to keep an history of the changes. Sharing the code is secondary. Backing it up is not even a feature.

The trick is that history is not the source control feature that is the most used. Just compare the number of update/commits on the last revision with the number of updates on older revision. Mainly, working with a source control is just updating on the morning and commiting before leaving. Browsing through history is not a daily activity.

That is why it is so confusing to switch to distributed source control. With distributed source control, history is the main thing. They considered this feature so important that they allow you to browse your history while being offline. You can share with others later.

There is some advantage to that. First, this is much harder to break the build. You don't have to push untested code or quick and dirty fix "just to save them" because you can save the history locally, do all the testing another day, and finally merge the whole history back with others.

Merge are easier too. With SubVersion, when a conflict occurs, you MUST resolve it before commiting your changes. But you may not understand the conflict and you really really don't have time to fix that right now. Because distributed source control keeps a whole repository locally, merging is not mandatory when a conflict occurs. You can keep the two versions and choose to resolve the conflict later. Or even ask the programmer that introduced the conflict to fix it.

That being said, I do think that all these software got the problem wrong. What I really want is my computer to keep an history of all the change I do, silently, without having to choose whenever I need an history point.

SubVersion or Mercurial both think that I am smart enough to know when I need to save my changes. They are wrong. I am dumb, an idiot. When I write a function, deletes it, quit my editor, and then want my function back, I am an idiot. An idiot in need of a really smart software to keep track of my all my changes.

(Sorry for the long post and any english mistakes.)

Well just in time.. I very recently adopted Subversion for our project. It was just the right choice for our team size(about 3 :)).. Even though the way it manages some aspect of source control differenlty, it was sure very easy to install and work with in Windows. The way in which it shows the status of files in windows explorer through icon overlay is a nice littel useful feature.

I also use VisualSVN Server. It's free and lets you set up a repository that's slightly different than what described here.

1) It uses Apache on Windows, and automatically creates an SSL (self-signed) certificate for you, so you can run it over HTTPS. (By doing it the way described in this article, you have no encryption -- everything is out in the open)
2) It stores the password in hashes, not plaintext, by using the Apache htpasswd authentication mechanisms.
3) It uses SVN authz files, which allow you have _granular_ control over a user's permissions for each directory inside each repository. And it provides the ability to control this in the GUI.

It has a great graphical interface, too. It's an MMC snapin, so it really makes it feel like it's a honest-to-goodness Windows service.

And did I mention that it's free? :)

Subversion is a great utility and surprisingly simple as well on Unix/Linux. Highly recommended!

Cheers.

"If a "checkin" occurs on your local machine, and nobody else in the world knows about it.. did it really happen?"

Well, that's the point. You can hack your feature locally, even use git to transfer between different machines, and the upstream does only need to know your complete feature patch, not the history to there.

Conversely it is also useful to review the history when offline. Granted, truly offline places are getting scarce.

And I indeed don't want every developer to wrap its head around distributed version control right now. Fortunately the git people seemingly are integrating a CVS server so you can offer boths models at the same time.

Bro - all this echo and no mention of Visual SVN server?

http://www.visualsvn.com/server/

Great timing Jeff thank you very much. Our software project (final year uni) is underway and our supervisor asked if we needed any tools installed on our drive. I brought up Subversion. The rest of my team have no idea what source control is. I have never used source control before, although I've done some reading. I figure it's a good time to get practising with real life tools for when we finally graduate and enter the work force.

Source control has not been mentioned or taught in any of our classes, or even recommended in our project assignment. It's thanks to reading this blog many articles ago I leart of the greatness of SC.

Cheers again.

For all Eclipse users try this plugin: Subclipse
I've been using TortoiseSVN, too, but Subclispe integrates seamlessly into the IDE, which is pretty nice.

http://subclipse.tigris.org/

Ruby on Rails Moving Source Repository to Git:
http://blog.wired.com/monkeybites/2008/04/ruby-on-rails-m.html

I just wanted to mention that those spaces after the equal signs in the sc command for creating the Windows service are REQUIRED. Kind of a weird looking command, if you ask me; guess it has to do with how it parses input from the command line.

I remember I wasted a good 20 minutes on that one the first time I was installing Subversion a few years ago.

I've used subversion for years - I have the server on a linux box running behind apache. Advantages of running behind Apache?

1) As another said, it's easy to set up permissions per-repository, or to have multiple access groups for a repositiory. For me this isn't the main reason (though of course I do serve the svn repos password protected over ssh) for using Apache.

2) This is my main reason - I can access my repositories from any computer with web access, so reduces dramatically any need to carry files around on a key drive.

Don't install crap into the system drive root.

> "If a "checkin" occurs on your local machine, and nobody else in the world knows about it.. did it really happen?"

From what I got from Linus's video, there's a lot more to the "offline in an airplane" scenario. You can have for example, a local feature being tested for two weeks in your own little test bed/testing department, then when its ready, merge it to the "main" repository. You'll be able to say, we have this feature and we have been tweaking (local committing) and testing it solidly for two weeks, etc etc. There's some more distributed SCM advantages explained there, such as having the test department having their own repository, expanding your trust sphere when merging by reducing your trusted merge vectors (linux kernel dev talk), merging is more importanting than branching, etc. Provocative ideas.

I doubt the human factor, but it sounds very technically enticing.

Linus's intense hatred towards centralized SCM (and not specifically Subversion, I hope) is In My Opinion (IMO), the view that it is slowing the software development process progress.

> promoting the old hotness ;-)

Yeah, Subversion is the old "black" for me, ever since the 1.0.x days. Very dependable. Backups are totally easy (svnadmin dump repository > onefile and you are done) and easy to understand. Also TortoiseSVN really is a great visual client. I always set up my Windows based SVN servers via Apache 2.x, because typing svn:// in emails just gets weird looks. I don't know how to install those fancy HTML interfaces, though. Seems I'll need to check out my options again.

I'm moving towards git, myself. I have a number of personal projects on it. The recent news that Ruby on Rails is moving to git from Subversion, as well as git public mirror repositories of GNU projects is also encouraging. The unofficial windows port, msysgit is usable if you like the command-line. Plus it comes with git-svn, a tool that bridges the gap between a Subversion server and git client, so you don't have to change your server infrastructure (?) right away.

Groking merging history is still difficult for me. Luckily there are some visual tools. For example (javascript required):
http://repo.or.cz/git-browser/by-commit.html?r=git.git

Still, git feels a little wobbly on the Windows platform (core.autocrlf :-( ), so I'm keeping my Subversion around for a little while longer.

Another advantage of using Apache is that you can configure it to use Windows Authentication (or LDAP), rather than maintaining separate user name and password lists.

VisualSVN is worth the money, sits on top of tortoise so you have source control in and out of the IDE.

There is also a free VisualSVN server for windows which will setup SVN w/Apache and provide a GUI management tool. It also handles using windows/active directory accounts for logins.

A few comments:

* You set up the standard svnserve daemon. This is great for just your machine, but should not be used for multiple users. I use svnserve for my projects at home, but I prefer to use either svn+ssh or http under Apache. Of course, this makes it much more difficult to setup under Windows since Windows does not include ssh (and all clients need it) and Apache can be tricky to setup under Windows. This is one place where both Mac and Linux beats Windows. Linux and the Mac comes standard with Apache, ssh, and Subversion. Nothing to download. Nothing to install.

* Many sites put branching under their project instead of the root of the server. This just makes more sense, and it is something that is mentioned in the official Subversion book. For example: svn://svnserver/FooProj/trunk instead of svn://svnserver/trunk/FooProj.

* Developers really like the way Subversion branches because branches are visible and it is easy to compare one version from another. Perforce also uses the same method for branching. At first, I was very leery of that. In all of the other version control systems I used, branches were internal to the file. You checked out the file and specified the branch you want. However, developers (especially ones that never used version control) like the visible branching system better.

* Tags (Labels) are a problems with Subversion because, as you mentioned, someone could checkout a tag and make modifications. I have a checkin hook that does some nice security functions. It is similar to the one that comes with Subversion, but mine also allows you to create groups, make sure attributes are set on particular files, and prevents people from messing up tags. You can create a tag, but you can't checkout the code off a tag and check it back in.

* One good thing about Tags and Subversion: Tags are not needed as they are on most version control systems. Subversion doesn't version files, it versions the entire source tree. Every checkin you do modifies the entire source tree. You talk about build 1238 which is the 1,238th revision of the source tree. That means you don't need to label every build. You only need to label releases.

* Seeing you set your editor to Notepad has made you lose a great deal of respect in my eyes. No developer should ever use Notepad for any purpose whatsoever. There are many excellent free line editors out there that don't munge your files.

* Why use Apache? Because Apache can be setup as secure, you can use Port 80 which is normally allowed through firewalls, and Apache has a better security system than svnserve. I usually setup my Subversion server to use Apache. You can even use SSL certificates (https) which allows you to do work without setting up a VPN.

* I am not a fan of "Git" because it doesn't do several things I consider important in source control. It is popular because the Linux team uses it. However, the Linux team does things very differently from most development organizations. What Git really allows is you to turn your checkout into another repository. For example, I do a checkout from the Git repository, then I can modify the code and do checkins and checkouts on my local machine. I can use branches, etc. When I am done, I check in my final changes back into the main Git repository. Even better, I could actually allow other people to do checkins and checkouts from my repository. So, I can checkout from the main GIT repository, then setup a GIT server on my system and allow my team to use the GIT repository on my system. Once we are finished, I can check everything back into the main GIT repository. Very neat trick. You can use SVK which is a Subversion add on that does a similar trick.

* I recommend that you take a look at Perforce. It is a commercial source control system, but you can use it for free for personal projects since you're allowed two users and five clients. (Users can have multiple clients which are just views into the repository). It is easier to setup than Subversion on Windows, and comes with its own built in GUI. In fact, two GUIs. One is p4win which is a Windows only GUI. The other is p4v which is a standard GUI that works across all versions of Perforce (Unix, Linux, Mac, and Windows).

* Yes, there are many commercial systems out there, but the advantage of open source version control is quite simple: I don't have any licensing issues. I don't have to track who has what license, I don't need a license key, and I don't have to get some bureaucrat in accounting to approve a new license whenever our department gets another developer. Plus, it is easy to justify the "expense" when it costs the company nothing to use.

We use Trac with our SVN server, so management occasionally uses the log for themselves and for generating activity reports for clients. Since a few developers never seem to want to detail their changes, we use a pre-commit hook to reject commits without comments. The hook requires grep.exe from the GnuWin32 project. Blog formatting may make this look ugly, but just toss this into pre-commit.bat in the "hooks" directory of your repository (edit paths accordingly):

@echo off
rem Add path to Subversion executable
set path=%path%;c:\Program Files\Subversion\bin

rem Add path to grep.exe
set path=%path%;C:\Program Files\GnuWin32\bin

SVNLOOK.exe log -t "%2" "%1" | grep.exe "[a-zA-Z0-9]" > nul || exit 1

exit 0

You should try mercurial one day.

+1 on visualSVN, it absolutely rocks. Not having your SCC available inside the IDE , is like having custard cremes without the custard.

Aside #1 - there is a fully integrated installer for Apache+SVN on the VisualSVN site.

Aside #2 - I've got a 500GB Synology NAS box, with the SVN client installed on it, its perfect, requires no PC and just sits on your network serving away. Ideal for small teams that want a self contained SCC box. I detail the SVN setup on my blog, here

http://runtothehills.org/rob/archives/25

although i did that well over a year ago, so the NAS box firmware may have changed (though i'm still getting comments that everything is ok.)
Cheers!
Rob

Take a look at StatSVN for reporting! We're looking for some outside help!

http://www.statsvn.org

Just to reiterate the previous comment, *please* correct the blog post, as Local System is effectively root == can do anything locally. Local *Service* (yes, the names are unfortunately very similar) is a very restricted account.

http://msdn2.microsoft.com/en-us/library/ms677973(VS.85).aspx

One advantage of running under the LocalSystem account is that the service has complete unrestricted access to local resources. This is also the disadvantage of LocalSystem because a LocalSystem service can do things that would bring down the entire system.

http://msdn2.microsoft.com/en-us/library/ms684188(VS.85).aspx

[LocalService] has minimum privileges on the local computer and presents anonymous credentials on the network.

SVK (http://svk.bestpractical.com) is a good free utility for SVN for distributed teams or individuals. Allows individuals or branch offices to host their own mirror of the SVN repository. Works really well for branch offices because it really reduces the bandwidth used for otherwise redundant bits transfered by multiple users. Also provides a built-in distributed backup. :)

"If you're an ASP.NET developer, you need to switch the hidden folders from ".svn" to "_svn" format, which is on the General options page. "

This is only necessary for ASP.NET 1.X. For ASP.NET 2.0+, you should stick with the default configuration.

Does anyone know of a svn plugin (like ankh) that works in sql server 2005 (or 2008)? I have heard that ankh works in the bi tools but I'm specifically hoping to find something that works in the sql server management studio.

@Tim

I second the recommendation for VisualSVN. I couldn't even get Ankh to work, but have been using VisualSVN for months and am very happy with it. Plus it leverages Tortoise so you don't have to learn a completely new UI for the same things.

"I'm skeptical. I've met precious few developers that really understood the versioning concepts in the simple centralized source control model."

That speaks a lot to the kind of people you choose to work with. The concept of working with someone who doesn't understand an appreciate distributed version control systems is just... wow. (And I'm not an old grey-beard or MIT Ph. D, I'm a kid a couple years out of a Java School)

@craig
Are you using VisualSVN in SQL (Management Studio) or in Visual Studio?

For poeople who want a place to put some personal code I can recommend assembla.com. They allow 500MB of free subversion hosting, which is the most I have seen of any free svn hosting service. They also have a Trac integration which is nice.

I (and my team) switched from CVS to SVN about three years ago. Now I'm considering switching to either git or Mercurial. Anybody just starting to use SVN now is well behind the curve.

The cool thing about a distributed code control system is that it has all the capabilities of a centralized system, PLUS the ability to do commits and branches and history without talking to the server. Sure, projects like the Linux kernel depend on it since they're inherently decentralized, but even centralized projects can benefit from being able to work without contacting the server.

Of course, I'm strongly in the "commit each conceptual change" school of thought, rather than the "commit each day's work" school of thought. It's important to me to see the steps along the way, and to be able to undo those steps individually. I use the commit history constantly, as well as the annotate/blame facility.

Also, Subversion's merge capabilities are painful to work with, while git and mercurial are designed to make merging easy. It's great that Subversion made branching easy, but it's nearly useless when merging a branch back to the trunk is such a pain. And even reverting a change is more painful in Subversion than it really should be.

Jeff, you may be interested in these links:

A guy who'd earlier explained why <a href="http://ww2.samhart.com/node/47">all distributed version control systems suck</a> switches from Subversion to Mercurial: http://ww2.samhart.com/node/49

Happenings in the version control system world (cvs, svn, mercurial/hg, bzr, git, as of March 1 2008): http://blogs.gnome.org/newren/2008/03/01/happenings-in-the-vcs-world/

After working with subversion for awhile now, I understand exactly why Linus has that opinion... I've come to the conclusion that subversion may sometimes be worse than no source control.

I set up Subversion on Windows 2003 about a year ago. I also had a Fedora VM (in VMWare Server) running Subversion on the same machine. I tested both from a client computer running Tortoise. The Fedora version ran faster. It was disgusting how much slower SVN was on Windows compared to Linux. Small commits were about the same speed, but large checkouts and updates were much slower on Windows. Another developer ended up discovering the same thing in his testing.

I don't know if this is an intrinsic problem with Windows (doubt it), or a problem with the SVN binaries for Windows (prolly). We ended up running SVN out of a VM.

There are two remote backup strategies that can be used with this scenario (that we considered). First, one can simply back up the entire VM to the remote backup device. The second strategy is to use NFS or an SMB share in the VM to backup just the SVN repository directories in the VM to the remote backup device. The nice thing about the first method is that it is very easy to stand-up an SVN server when an emergency strikes, or just to stand up a backup when needed. VMs are so easy to use anymore, and VMWare Server is free. You can even download a very light-weight Linux/Subversion "appliance" VM image from VMWare. Some food for thought when setting up SVN.

Oh, and I loved using Subversion. I have used VSS (oh my god), Vault and CVS, and Subversion is better than all of them. I am back in CVS land now, which is also a very good repository.

SVN really screwed up tags. They should be mnemonics for revisions, like they were in CVS, or like the magic revision name "HEAD" is. So instead of:

svn diff --summarize $REPO/tags/some_random_tag $REPO/trunk

You could do:

svn diff --summarize -r some_random_tag $REPO/trunk

It appear a small difference, but it is conceptually much cleaner. You also wouldn't be able to accidentally tag just part of trunk, which is possible now with the copy cop-out.

Meh.

I forgot to mention a big reason I'm considering switching from Subversion to a distributed system. Often one of us will embark on a set of changes that will break things until done and tested. The right way to do this would be to start a branch, but as I mentioned before, merging is painful in Subversion. It's certainly scary enough that the rest of my team doesn't want to touch it.

So one of two things happens: either they go ahead and commit as they go, breaking things for everyone else, or they don't commit anything until they're finished, so there's no history of what they're doing.

With a distributed system, branching and merging would be trivially easy, and everyone could make their private changes locally, then push up to the shared server when they think everything is good. And no history is lost.

I've actually spoken with SVN developer Brian Fitzpatrick, and he said that SVN will indeed be getting distributed features similar to “the Mercurial model.”

Learning DRCSs is easy and as simple as watching a few Google Tech Talks (Google being a SVN user themselves with Google Code):

http://humani.st/learning-distributed-revision-control-systems/

Distributed revision control is simple. It's just a repository of non-distributed repositories. "Push" and "pull" are essentially the only two new commands to merge between repositories. Everything else is the same as SVN (of course this is a wild simplification).

For those interested, my reasons for using git are (though I usually use it with git-svn with the main repository in SVN):
- everyone has the full history of the project always.
- This makes searching for the cause of a regression and some other things easy even when offline.
- Especially for OpenSource projects it also means it is near impossible to loose your history (there are thousands of backups).
- I can have branches with hacks that are not suitable to be published and the merging with new features from the main branch usually works quite well.
- Even though I have the full history, it uses less disk space and is faster than SVN (having to do manual compaction occasionally is a bit annoying though)
- For reading it works just fine over plain http without anything special (so I only need ordinary web space to publish it), and writing works well via ssh. So all you need for a fully functional, public repository is web space and a shell account - something e.g. every student, at least around here, has.

I use Subversion and have done so for the past three years. I have taken a look at GIT, but since I'm spoiled with TortoiseSVN I haven't really seen any reason to switch.

GIT is much more advanced, and branching/merging in SVN is clearly not what the thing was built for.

But in a case of "worse is better", I stick with SVN. It does everything I need and I can easily convince myself that I don't need anything it doesn't supply.

VisualSVN + VisualSVN Server FTW. The server even lets you do Windows authentication with the latest version.

I think every developer that sets up a svn a few times ends up writing the exact blog post you just did Jeff :) I know I did a few months back and there are dozens out there that read almost exactly like this one. Of course the only difference betweens yours and others is that you probably have a few more eyeballs on it and getting the source control word out there for every developer is key.

Personally I love svn and set it up on my Windows Home Server, which makes a great repository server. Couple that with how easy it is to integrate with all the CI servers out there and it's a winner.

I have just given this a go I have been thinking about source control for a while but not got round to it as I am one of just 2 developers usually working on separate applications. However obviously the advantage is you make a mistake or need some old code back that you removed you have it.

I successfully setup this on my home computer my question now is, if I install subversion at work and tortoiseSVN can I just copy the repository directory to work and use and update it. Then take it back home replacing the old one and repeat as I go.

I regularly take my work home and can't map a network drive or anything like that to share between the two. Alternatively is there somewhere on the net I could store it.

Thanks in advance.

Also I have several different folders in different locations should I use a separate repository for each of these. For instance I have visual studio 2008, ms access apps, visual basic 6 apps, documents. Or is there a better way.

Yes, all that is great (I use Visual Svn Server to make the server installation more palletable for the groups I consult for), but I have one question:

What is the purpose of ascii-RickRoll.txt?

Wait, I already saw the music video. Don't make me relive the 80s.

I have been using SVN happily for a long time. It's what CVS should have always been (revision number per file? WTF).

I still don't see the point of distributed SCMs. I guess I will keep staying away from them until I see the need. For now, they feel like a solution for a problem I don't have (just like almost all C++ features *used* to be, to me).

Heck, even branches looked to me like a disorganized way to work, until one day I needed one, and I got enlightened :) Maybe some day the same will happen with distributed source control...

Just read the article, and set up SVN+Tortoise for my future development works. Fantastic stuff. =)

A word of warning, though: Jeff, you might want to re-check your link to the Tortoise site, since it's missing the last T. I woke up thinking slow (blonde-girl-slow, actually), and I refreshed like five times before figuring out the domain was .net and not just .ne like it's posted. =p

Still, cheers on the awesome work.

Is nobody going to comment on ascii-rickroll.txt?

Not wishing to be a nitpicker... but regarding "If you're an ASP.NET developer, you need to switch the hidden folders from ".svn" to "_svn" format, which is on the General options page."

That was only for *Visual Studio* 2003 and earlier: <a href="http://blog.dotsmart.net/2008/02/19/moving-on-from-svn_asp_dot_net_hack/">http://blog.dotsmart.net/2008/02/19/moving-on-from-svn_asp_dot_net_hack/</a>

"What is the difference between what you describe, and working traditionally offline, then checking in when you get back into the office?"

I think they call that change management. ;)

Generally it gives you more control. I tend to make checkins in a way so that I can apply single patches in the trunk or in some particular branch.
Try sorting out all those little changes for several unrelated things - which easily happen even on a short two day business trip - when your back in the office and you'll understand.

Unwritten rule for me is one check in - one change. This makes all those little bugs I might have introduced much more traceable.

I believe the distributed vs centralized source control system debate all revolves around the working environment that the developers use. The various features of distributed source control systems that "are great" that have been mentioned -- like the ability to have multiple repositories for test vs development vs each person, etc, that's not the providence of a distributed source control system, it's a feature of a good source control system with good branching support. I do that in Perforce all the time -- development vs test vs release, with occasional labeling.

I believe that developers like Linus and other Linux developers operate in a more disconnected, more distributed environment than, well, anyone has in the past. A single repository doesn't make any sense for them, which, well of course means that every source control system that existed in the past doesn't work for them. Like all good software developers, the went off to write their own tool.

The one feature that they really get is the ability to run disconnected from a server and still commit, which is nice, but not always required for all developers.

However, I worry that, for projects that don't actually need a distributed system, like say, a "group of people in a single office working on software", I worry that a distributed source control system would just be a excuse for people to follow bad team development patterns. Sure, they'd all have change control for their own checkins, but I rue when "merge day" appears and everyone breaks each other's code.

I'd also add that a centralized source repository makes it easy to meet other business (not necessarily development-centric) requirements -- single point for backups, long term tracking of code, configuration control, etc etc.

I use Perforce at work. I like it. I have seen continual additions of features in the 3 years I've been using it, I've had excellent support, and the only time I would think of using anything else is if I had no money and multiple developers, at which point I'd probably use Subversion.

The fact that you think dvc systems are somehow _more_ complicated than the original centralized model amusingly proves your own point, but not how you intended.

The real reason we'll be stuck with subversion for years to come is that most mediocre developers wont take the time to learn new tools and new ways of doing things, and therefore will never grok distributed version control.

Codemonkeys ftw, unfortunately.

HI, with this notepad popup when you commit something - did you try to specify -m flag with a message eg svn commit -m "test"? atleast, on unix it takes care of that.

"When it comes to readily available, free source control, I don't think you can do better than Subversion at the moment."

Except by using the much superior Git.

I did a post about setting up SVN without a server that you'll find helpful.

http://www.sleepoverrated.com/2008/04/06/GuerillaDevelopmentSetupSourceControlIn60Seconds.aspx

I recommend people use VisualSVN Server too it gives you https easily

how about http://bazaar-vcs.org/?

svn was single-central-repo model source control

I'd prefer something more distributed

I really like SVN plugin for Visual Studio integration by PushOK software. It's cheaper than VisualSVN ($29.99) and its a MSSCCI provider, so it uses the same source control window that comes with VS. Plus all MSSCCI aware applications will automatically just work.

http://www.pushok.com/soft_svn.php

> I rue when "merge day" appears and everyone breaks each other's code.

I watched the rest of Linus' talk at http://www.youtube.com/watch?v=4XpnKHJAok8 . Git *enforces* per-developer personality-driven p2p branches. This is great for ego-driven people like Linus who have a lot of power, fame, and personality. That makes sense. :)

I'm really intrigued by Linus' claim that merging becomes extraordinarily simple in Git. He's absolutely right about that-- the problem with branches isn't the branching, it's the merging.

Still, I'm unclear why merging would be inherently "easy", except for trivial diffs where there's no overlap in the lines that were edited. It seems the tooling could be improved on the SVN side to make this happen, if that's all he's referring to.

The social aspects of distributed source control are pretty compelling, though. It "works more like people work" is arguably true.

I've tried to introduce Subversion at work, to replace Visual Source Safe. Our problem is however that we deal with Microsoft Reporting Services reports. A change to a report will usually restructure the whole file, shuffling bits and pieces around and creating total pain when merging. Not to mention that reports can get quite big (5000-6000 lines) and it annoys me greatly that subversion inserts it's '<<<<<< 1.2' merge tags into them.

Exclusive locks are, I think, the better option in these cases. Is there anything I could do to subversion to make my life easier when dealing with these cases?

I guess it all depends on what type of software you are trying to control. At a previous employer our code was mostly binary files. Although IT hated it we had little trouble with VSS. And SVN was a nightmare. Just that one experience soured my opinion towards "free" open-source software almost irrepairably.

One nice thing about Git is that it does not leave .svn turds in all you directories.

"One nice thing about Git is that it does not leave .svn turds in all you directories."

That's a good point - I've really gotten used to (in linux) typing rm -rf `find . -type d -name .svn` to clean out a chunk of code so it's ready to share.

Is there an easy way to do the same on the windows command line?

(That aside, thanks for the tutorial. I'm a big fan of svn in general, and that looks very useful.)

"I've met precious few developers that really understood the versioning concepts in the simple centralized source control model. "

Probably a lot of them VS.Microsoft devs? Brought up with Visual BASIC and SourceSafe. I understand why they wouldn't understand.

Sorry if I seem to not understand something, but if you're going to use TortoiseSVN anyway, why not simply right-click on a folder and select "TortoiseSVN->Create Repository Here..."? I have done this multiple times, and have had no issues whatsoever.

@Nicholas Wright: If you *want* it centralized, SVN is the best you can find. There are other dozen open source SCM software but they're all distributed.

@John Fiala: "svn export" is what you need.

@Ilici: use exclusive locks, *or* find a tool that would merge them correctly.

Another fan of PushOK here - I've used Ankh before that and seen VisualSvn, and IMHO the PushOK software really beats them because of the MSSCCI integration. In English, that means you can check in a new project and not worry that it is also going to check in the dll's and pdb's and so on.

The only thing that I've noticed that PushOK will do (on a multi-file check-in on a multi-project solution) is commit each project to a separate revision number. If you check in using Tortoise from the solution root, you get it all in one revision number.

PushOk also supply a piece of software to monitor file changes if e.g. you use Tortoise to update files. It is designed to fix the mismatch between MS Locked-check-out development and SVN's unlocked, everyone checks-out files (then potential merges on commit). It is a little flaky, however... but this has proven an issue with Ankh and VisualSvn too.

Nij

Jeff, there's an easier way to get SVN running and it gives you an integrated Trac instance as a bonus: download the free Trac/SVN JumpBox here->
http://www.jumpbox.com/app/trac

It sets up in under a minute. You can use it without registering. And the other benefit is it's a self-contained, portable artifact that you can leave behind with a client when you finish a project.

sean

WHAT?! Recommending starting with Subversion, in 2008?! WHAT WHAT WHAT?!!!

Even for my extremely simple needs (no merging or splitting, just a straight line of modifications), Git has been vastly easier than SVN. It is much better at handling deleted and new files, and it is much better at realizing when files have been renamed or moved, even when they've also been modified greatly. SVN whimpers and cries from these things.

If you've only used CVS/SVN all your life, maybe sticking with it could be a good idea (for now). But if you're just starting out, it would be wiser IMO to go with something more modern. Why take on outdated baggage if you don't have too?

To integrate SVN with Visual Studio, I use something like this, which is completely free: http://garrys-brain.blogspot.com/2006/11/visual-studio-2005-and-tortoisesvn.html
It actually integrates with TortoiseSVN, not SVN itself. But it works well enough for me.

For VS2003, which is what I use most, I set up a bunch of "External Tools" commands that point to TortoiseSvn. I have one for "Diff", "Log", "Update", Commit", and probably others. Then I just add them to the toolbar. You can even add the matching TortoiseSVN icons to the buttons if you want.

In a nutshell, no need to buy anything to integreate SVN into Visual Studio - it's super easy.

For source control on my personal project (as in, I'm the only one who accesses the repository), I've found Git to blow SVN away (for my purposes). The main reason, is because it is distributed, I don't have to set up a repository on my local machine. I love how easy branching is. But like I said, this is only my experience - I have no idea how SCMs or DSCMs scale up.

I've been using Subversion for a couple of years on an ASP.NET 2.0 project. I do not host the server myself, however, although it is easy to do. I use www.cvsdude.com (I am not affiliated with this company) and it is awesome. I'm automatically backed up off-site and I can manage user permissions, modules, etc. through a nice web interface. There's also a nice web view of all of the repositories for doing diffs, history, etc. I'll gladly pay a monthly fee to avoid any potential headaches with running my own server...

Has Git support for windows/Cygwin improved any? I've considered trying it for personal projects since everyone has had so many good things to say about it's branch/merge/tracking model.

But since I still work in windows land and afaik Git support for it is still crap, I've been looking more towards Mercurial for my DVCS needs, though I haven't started on a new project recently so haven't properly implemented one on my systems "properly" yet, though hg is on my laptop waiting for use ;).

Subversion is a great tool. If a server setup is what you are looking for then running it atop a linux box will do higher justice. For windows there's Virtual SVN for server setup http://www.visualsvn.com/download.html

OpenSource Rocks!

Thank for the great post. Its a great help!!! Love the blog.

VX

With respect, this seems years too late. ;) http://svn1clicksetup.tigris.org/ solved this in September of 2005. Not to mention VisualSVN Server.

thanks! man really interesting and educating article.

I am glad that there are many individual developers who download Git and say "it works great for me". The first job of any source control tool should be to make sure that no source ever gets lost, and secondly, that you have the tools you need to go back and figure out what the hell you broke.

However, like I said above, the second stage of source control is when you start using the tools to interact with other developers, and, if you're, err... lucky?, non-developers. Git seems to work quite well for the anarcho-meritocracy of open source development. No need to worry about angry "Core Team" developers withholding commit access here!

Now, a more traditional development environment though, I'm really thinking Git lacks the "management" features of other tools. Of course it does, that's the whole point!

I don't think it's possible to have a context-free debate about source control: it's very dependent on what platform/languages/tools you are using, the development environment, the development process (if there is one) etc.

I haven't used AccuRev (http://www.accurev.com/webinars/20061004_scm_accurev45.html) in production, but it looks like it rocks to me.

Now I just need to persuade management to fork out the bucks!

> With respect, this seems years too late. ;) http://svn1clicksetup.tigris.org/ solved this in September of 2005.

I saw that, but then I saw the latest package was January 2007 -- so I assumed it was out of date. Is it normal not to have a release in 14 months?

Also, be sure to read Bill de hra's excellent response to this post:

http://www.dehora.net/journal/2008/04/06/what-a-dvcs-gets-you-maybe/

Subversion is OK as a VCS, although I find it a bit clumsy in some areas.

The big problem with it is the clients - I have never found a good one. The best is the Subclipse plugin for Eclipse, IMO, although I prefer a standalone client. Clients integrated into IDEs have a habit of being too helpful :-)

TortoiseSVN is a PITA. It shows the wrong view. I can already see the files on my computer, thanks very much. What I need in a VCS client is the ability to see what's in the repository, what branch I'm in, file history etc at the same time as seeing what I've changed on my machine (which is the least important view in some ways). The only way to get that sort of thing in TortoiseSVN is painful and clunky.

Unless something is checked in, it doesn't exist in the project. The repository is where you build release versions from, where your continuous integration gets its code, and so on. So management of that is key. I want to see what's happening to it, and with TortoiseSVN, that's too difficult and too poorly done.

git and other systems do merging more easily than subversion because that was regarded as an essential feature, and because they (deliberately) force simplifications.
In subversion (and CVS) one can branch and merge arbitrary sets of files and directories.
In most systems you can't: a revision consists of a specific set of files and directories (which can change over time, obviously), but it gets changed, branched, tagged, merged, all in one go. So merging's going to be easier (and faster) in that case. Also more easily comprehensible, I suspect. It'll be interesting to see how subversion's merge tracking in 1.5 plays out if and when it's actually released.
Another strike against subversion is that when it checks out something it stores an uncompressed copy of it so that you can do "svn diff" and things without contacting the repository.
That's an advantage over CVS but a disadvantage compared to almost all other systems: you typically get the entire history in less space than that copy of one revision. In some ways that's trivial (disk space is cheap and all that), and it seems obviously fixable (just compress the copy) but it's been fixable for several years so a fix probably isn't imminent.

Jeff, Apache gets you a WebDAV folder to access the latest version. If you want to edit just 1 file (not the directory which is SVN's default working model), you can just drag the file off the "network folder", edit it and drag it back. Voila - you just checked out, modified and checked-in a file. Perfect for 'non-technical' users. Just make sure you have the exclusive lock option set :)

I've found SVN to be good, but not for corporate development.

Its merging facilities are trivially easy to screw your source. It only takes 1 poor checkin to garble things and that is not acceptable at all. I ended up putting exclusive locks on everything to prevent this.

There's no global configuration options. I cannot prevent build objects from being checked in, or to ensure all developers have the same options.

It dumps ".svn turds" all over your filesystem. I know this is part of the design and dsc space is cheap, but when you have gigabyte source trees, it becomes difficult to manage.

The GUIs I've seen are poor when it comes to displaying branches. As tags are branches, this is quite important. Also, with sub-projects having branches from the project directory quickly becomes a managment nightmare. (though this isn't necessarily a SVN issue, it doesn't make managing the problem easy which is).

There was also an issue where the .svn directory became corrupted/deleted. You have to check everything out to a different directory and fiddle with copying them back. There is no 'get the latest as .svn and then let me do a revert/update/checkin' which I got hit with several times. (The 'working copy locked' problem if you read the mailing list archives).

John Fiala: >>>
That's a good point - I've really gotten used to (in linux) typing rm -rf `find . -type d -name .svn` to clean out a chunk of code so it's ready to share.

Is there an easy way to do the same on the windows command line?
>>
(That aside, thanks for the tutorial. I'm a big fan of svn in general, and that looks very useful.)
<<<

Oh well. And try the SVN manual some time. It sure looked useful to me.

Vinzent.

@AndyB & Vinzent: Delete SVN Folders (Windows) - http://weblogs.asp.net/jgalloway/archive/2007/02/24/shell-command-remove-svn-folders.aspx

> What is the difference between what you describe, and working
> traditionally offline, then checking in when you get back into the
> office? If a "checkin" occurs on your local machine, and nobody
> else in the world knows about it.. did it really happen? Maybe I'm
> not understanding the distinction here.

The difference is that you can make gradual commits while offline, so you still have all the benefits of source control while offline and a complete history of what you did while you were offline. You can also clone the repo as many times you want and try stuff out. And when you push it back, all the commits you made while offline are visible to others.

With SVN, you have a working directory, but you can't keep track of the changes you did while offline. So that's why many people then revert to making backup copies of their working directories, which really defeats the purpose of source control.

Also, cloning a repository, commiting to your local repo several times and then pushing back when you're happy with it promotes more experimentation. With SVN I don't want to go through the hassle of creating an experimental branch for something stupid and I don't want to commit my changes until everything works perfectly, so with SVN you many times end up with these huge commits.

I'd suggest you give Mercurial a go, it's simple and really easy to install on Windows and when playing around with it for a bit, you see the benefits of a decentralized VCS.

DreamHost.com offers subversion as part of it's basic hosting package which is really inexpensive. For the record, I LOVE subversion. Thanks for the post. I will have to checkout VisualSVN Server mentioned by your commenters. I, too, setup my Win server with apache but it took several hours too get it right.

Seth Spearman

Just an FYI to make merging easier check out:

http://www.orcaware.com/svn/wiki/Svnmerge.py

@Jeff
>> Setting up svn in Apache is more complicated,
>What does that get us? Some kind of web UI? Use of port 80?

If you want to authenticate users against a windows domain, you should go for Apache + mod_auth_sspi combo. One password to rule em all ;)

Its funny how Jeff has mentioned Git without saying its name.

I just started playing with Git on Windows about 4 months ago, and I'm hooked. The hype around it I never really understood. I mean literally. I had no idea what they were talking about. Might as well have been in Swahili. Well, I *still* have no idea what they are talking about, but its sure great for our needs.

We have to deliver our systems to customer sites all over the world. Of course there's often a bit of "integration" required at the customer site, which means code changes. Thus we are accustomed to syncing with repositories remotely over some of the slowest and/or least reliable internet connections imaginable.

Git was pretty much designed for exactly these conditions. It only requires a link to the remote master repository when changes need to be merged. (In a pinch, the changes can even be emailed. In an even bigger pinch the local repository can be copied to a laptop or USB drive and physically sent home.)

Rather than listen to all the back-and-forth hype, I'd simply suggest trying Git out yourself and seeing what (if anything) it can do for you. There are several Windows ports floating around, but I think the friendliest is Msys Git at http://code.google.com/p/msysgit/ . It has a nice installer what will add a "bring up the Git Gui here" option to your explorer menu. That's all you'd need to get started.

> Has Git support for windows/Cygwin improved any? I've considered
> trying it for personal projects since everyone has had so many good
> things to say about it's branch/merge/tracking model.

I don't know what it used to be like. I do know that its at least as good as Subversion's was 2 years ago when I last looked at it. My only complaint is that Git Daemon could use support as an NT service. I may do that myself if I can scrounge up the free time.

As I mentioned in the previous message, I'd suggest using the Msys version. Just go to http://code.google.com/p/msysgit/ and click on the "Featured Download" on the right.

You can also get Git as part of the Cygwin download ( http://www.cygwin.com/ ). You have to manually select it from the installer though, and it installs a whole bunch of other Unixy stuff and DLLs too. It doesn't give you the nice "Start Git GUI here" right-click explorer menu either.

I personally use Eclipse while the rest of my team uses Tortoise. It didn't take that long to get Eclipse working with it (it even auto-detected the tortoise files and setup) plus it tells me whenever my files are out of sync with the repository AND has a built in compare editor. I've used it for Java projects as well as Coldfusion with much success.

I watched the whole video. There are a couple quotes of his worth mentioning:

"In a tightly controlled environment, centralized systems work better."
(Yes, Linus said that)

"Merge often, merge early."
(If we do the same thing with update and commit in a corporate environment with subversion, don't you get much of the same benefits?)

Here is a great explanation of the text file captured in the screen shots: <a href="http://tinyurl.com/2q9j9y">http://tinyurl.com/2q9j9y</a>

I agree Subversion is the best. I use TortoiseSVN and VisualSVN which is great for VS since you don't have to leave the IDE.

I get the feeling that SVN and other non-distributed systems are dead or dying and we'll all move to systems such as Git and Mercurial.

I actually used CVS to maintain some of my own single developer projects, but even for these micro-projects, there's no reason not to use these distributed system.

The easy branch/merging on Git is great for even a single developer to explore a line of development and revert back or merge the changes.

I've set up SVN quite a few times and this is a pretty good tutorial on such. Well done!

> I get the feeling that SVN and other non-distributed systems are dead or dying and we'll all move to systems such as Git and Mercurial

No, there will be a split.

1) Tightly controlled development will remain the providence of centrally managed source control.

2) Non-tightly controlled development or development with a anarcho-meritocratic hierarchy of developers(the self-directed people who happen to post a lot on blogs!) will all go to distributed source control.

By the way, again, I read about the problems with Subversion and merging, and I never have these problems with Perforce and merging, nor ".svn turds" or "CVS turds" or whatever.

And you wonder why people choose SourceSafe over subversion??

I just counted about 15 steps that could easily be screwed up by anybody on a team of 10+ people who are used to the simple GUI of SourceSafe.

Remember about the 80% of programmers you talked about here:
http://www.codinghorror.com/blog/archives/001002.html

When you're setting up source control in a shop at work, you have to follow the keep it simple approach or people will start breaking out of it because they just don't understand it.

SourceSafe might not be the most secure and wonderfully functional piece of software, but it doesn't take a lot of brains to set it up, and it provides some basic functions to the large percentage of Microsoft programmers who want something simple.

Want to set up a SourceSafe client or server? Pop in the CD and follow the simple GUI prompts. Want to add your project to source safe? Check the box that says "Add to Source Control" when you're creating your project. Nothing to execute at the command prompt, no standard TTB folders to add, no cryptic config files to edit, it just works.

>>> 1) Tightly controlled development will remain the providence of centrally managed source control.

You can still centrally manage source code with Git.

I've recently become a fan of Mercurial, one of the distributed source control solutions. Like subversion, it's got a simple clean syntax, and is free & open source. While I don't even remotely agree with Torvalds' "subversion is evil" position (in fact I really like subversion- It's my favorite of all the centralized systems) there is some convenience to the Distributed model. My personal favorite element of it is that you can commit to a local repository, meaning you can work and save your changes while offline (say, on a plane or something). Then when you get back to somewhere with a connection, you can push those changes to a centralized (potentially off-site) repository. I know some people consider it "cheating" to still have a repository considered to be the central one- I really don't care. To me, Mercurial is like subversion with a little more flexibility tossed in. I'd recommend giving it a shot.

Curious thing. Yesterday I was looking into installing Subversion on my Windows machine so I could play with Scala.

Now, many years ago I was a FreeBSD committer and, as such, comfortable with CVS. Since then I have been using Dimension/PVCS, and not as a programmer, and I'm fairly happy with it.

But, yesterday, I was not happy. I didn't like what I saw with Subversion. Too heavy, it seemed to me. I looked up an old favorite I never got the chance to use, Darcs, and I wasn't happy again -- no Eclipse plugin and, frankly, Windows install seemed an uncertain proposition.

I might check Perforce. The FreeBSD team was using it about the time I was a committer more in name than in actions. For my purposes, maybe it will work fine.

Anyway, let me drop a piece of wisdom to those who are considering version control just because of this article. One change, one commit. Do NOT "checkout at morning, checkin by evening".

When you do a commit (check in, or whatever you want to call), you are supposed to explain what was the the intent. What were you trying to do? I say this because _my_ usage of versioning systems have always been history-heavy. If a version control system doesn't have "annotate", it sucks.

The thing is, once you find a bug, it is very important to understand why the bug is there. The bug, very often, is actually doing something else correctly, the bug being a side effect. So, to avoid breaking something else when fixing a bug, and even to help devise a fix for the bug, it's very important to know when the code came into being, and what was the intention of the change.

It might also help to make clear what is working or not on your development methodology.

Plastic SCM http://www.codicesoftware.com/xpfront.aspx looks interesting, but I haven't been able to find any good reviews of it. They are advocates of a branch per task philosophy which makess more sense to me than mainline development.

Anyone heard of it or have any opinions?

would be better if you had taken another 5 minutes to show its integration with Netbeans.
...i know..some people are never satisfied...

Here's a good place on how to set up svn+trac -
http://inner-rhythm.co.uk/TV/

>>> 1) Tightly controlled development will remain the providence of centrally managed source control.

> You can still centrally manage source code with Git.

Quite. There's nothing stopping anyone from using Git just like Subversion. There's even a module for using it with Subversion repositories.

What Git buys you is more options. That's the thing that got me so jazzed about it.

Source_Control = "YAWN"

<a href="http://blogs.vertigosoftware.com/teamsystem/archive/2006/01/16/Setting_up_a_Subversion_Server_under_Windows.aspx">http://blogs.vertigosoftware.com/teamsystem/archive/2006/01/16/Setting_up_a_Subversion_Server_under_Windows.aspx</a>

I use RapidSVN as a client, up to now the best (as I don't only develop in one ide and don't like tortoise's funny icons)

Regards

As a student that has never successfully used VC, I have found both of these discussions enlightening. For my project today, I copied some files manually, and renamed them manually, and changed my header files to the renamed files. All so I could test an extra credit feature. This sounds to me most like a DVCS type feature. Now if I can just integrate something into emacs... ;)).
Really, I appreciate these type of discussions. These types of posts are the type I read Coding Horror for. These are the posts that make me overlook your MS friendliness.
Great Work Jeff

Sorry, by posts I mean de Hora's, and yours, Jeff.

Notice that when you gonna write

sc create svnserver binpath= "c:\svn\bin\svnserve.exe --service -r c:\svn\repository"

you must respect every whitespace (epecially the one after binpath=)

> And you wonder why people choose SourceSafe over subversion??

Please do not use SourceSafe.

http://www.codinghorror.com/blog/archives/000660.html

Subversion takes a tiny bit of work because it's free, but there are also lots of commercial source control providers (Team System, Perforce, Vault, etc) that are infinitely better choices than SourceSafe.

the warning against sourcesafe is just ab it of personal choice. For some programmers it is the far better choice than subversion with all the lacks of svn and vs integration

There are several free-ish (as in $5 a month) repository providers on the web. Well worth checking out and useful for small teams without the hassle of setting up the repository yourself.

@offler

I'm sure there are SVN hooks into VS - both products have been around far to long for this not to be the case.

Don't know if anyone else had this issue w/ setting up the root level folder for the new project on their Windows box:

Tutorial instructs:
set SVN_EDITOR=c:\windows\system32\notepad.exe

Results in:
sh: c:windowssystem32notepad.exe: command not found
svn: system('c:\windows\system32\notepad.exe svn-commit.tmp') returned 32512

Correction:
set SVN_EDITOR=c:/windows/system32/notepad.exe

/\Yes, coffee is the great illuminator./\

If you just want to use SVN for working on local file repos you don't need to go to all that hassle, just download & install tortoiseSVN, it has everything needed to create and work with local repos without needing any other setup.

SVN sucks when you need to manage lots of code and lots of branching/merging. Having used perforce before, I can attest that SVN really does suck when it comes to merging - everyone hated on my team except PHBs who loved it because of the ZERO sticker price (but didn't consider the lost productivity time using the tool).

I found that merging or back-merging to a main trunk to be a chore simply because you had to physically keep track of revision numbers that you want to merge. I hear SVN 1.5 will fix this, but the world is still getting burned using 1.4.

Not to mention that there are a handful of backmerge processes that you can follow, depending on your branching strategy only complicates matters further.

Sheesh...merging shouldn't be that hard.

Linus' argument on why central source code management sucks: if you have a million users all operating in check-out, work in disconnected fashion, and then having them merge their changes into a main trunk is very difficult due to the fact that kernel code is prone to breaking a lot when data structures change, APIs change, etc.

So either you give EACH user their own private branch within a central repository which is very expensive storage and compute wise and huge server burden OR you go to distributed mode where EACH user HOSTS their own repository.

Now if Linus wants to see your changes, he simply checks out YOUR repository. If you want some changes integrated into your repository, you simply pull changes needed from one repository and add them to yours!

Yes the concept is similar to private branching, but more flexible I think.

The question is, who's repository is GOLDEN, e.g. the official repository for code releases, and Linus' is the declared one here.

kashif

I don't think anyone's arguing that centralized source control is right for the Linux kernel. Of course it's not, Linus controls the project and wrote his own tool which matches exactly the way that the Linux kernel development works. A centralized source control tool for Linux makes no sense since development is decentralized.

I think distributed source control matches open source development quite well, but it does assume that there's some process for merging. Unlike centralized source control, there isn't a definite place one goes for code unless someone sets it up and says "here's the place to go and this is how we will merge code and etc etc".

The real question is whether a decentralized tool can ALSO meet the development needs of a centralized development environment.

> The real question is whether a decentralized tool can ALSO meet the
> development needs of a centralized development environment.

You should be able to work as "centralized" as you want with pretty much any revision control system I've seen.

However, I think a lot of people will be suprised to find, as I was, that their development environment is only rigidly centralized because their old revision control tool forced it to be. The human processes tend to flow organically around the limits of the tools you use. You can end up with a lot of unwritten meta-data that has to be learned by new employees. You may never even notice this if you don't have any experience with different tools.

That's why I'd suggest everyone spend a little time playing with new tools when they can. Even if you never use distributed revision control (or functional languages, or Unix, or Emacs, or ...) it will change the way you think about the tools you *do* use. Expanding your bag of tricks will make you a better developer all around.

Give me a distributed VCS that doesn't use huge hex strings to identify revisions, works decently on Windows, and has Eclipse integration; and a sourceforge-like site supporting it, and *then* I might start looking at the distributed model.

till that exists, svn will do :)

Interesting, I'm currently following the Blog of Brian Di Croce where he presents the steps to install your own CIE (Continuous Integraton Environnement). The first step is the installation of subversion, not as in detail as yours, but quite interesting. He also presents the installation of TeamCity from JetBrains.

You might be interested, http://blog.briandicroce.com/

Sylvain

After looking at svn and using it for a couple years, I've decided that it has a number of serious problems. I've posted some extensive commentary here:

http://blogs.sun.com/smarks/entry/why_i_don_t_like

s'marks

Well reading some comments, I'm wondering if some have ever use Subversion before ? My experience with sourcesafe were a nightmare, corruption of data was one of the problem I got. I was using it though, I did not configure it myself so I don't know if it was easy or not.

But I have setup many subversion and never got any problem. On linux it's a matter of simply install a package and change the config file, so pretty easy. I also setup a Trac environement for the research project I'm in, it's really useful and easy enough to skip the 50$ License for JumpBox.

I'll look in Mercurial tough, I did not know it and I think it could be more appropriate for our project at http://sonia.etsmtl.ca

If you search for "subversion" in the vmware appliances page, you get 40 hits:

http://www.vmware.com/vmtn/appliances/directory/cat/53

Has anyone used a subversion appliance (or a separate computer on a LAN) with something like no-ip.com ?

I recorded a screen capture of this subject awhile back available here:

http://www.stevetrefethen.com/videos/Continuous%20Integration.ashx

I gave subversion a try after reading this post, and personally find it a bit lacking and difficult to use compared to Perforce, which is what I use at work. Maybe after using it a bit more I could get used to it.

Hi Jeff

Regarding the restart workaround you suggested. I've also tried logging off and then logging back on that's a cleaner way to stop and restart explorer. It's faster than restarting on my rig, might not be so on yours.

I worked in Microsoft; and my project is still using SourceDepot, which is rigid. So, I setup a personal SVN environment for source control. I like SVN because it is easy to use and it is well supported in Windows dev environment. There is TortoiseSVN and AnklSVN making life easier.

The main problem is that if I code in home at weekend. I cannot commit my code. This may not be a big issue since I can check code in when I am back at office(I set my repository at my desktop machine). However, from time to time, I really hope I can check in locally and then merge it back to repository. I heard about GIT which is distributed SCM, but seems it is not well supported in Windows.

Our team is evaluating options to replace PVCS right now. We are mainly looking at open source and evaluated SVN.
The conclusion, subversion was a no go. Use case after use case and it fell on its face. The main issue with it is the model that it is built upon. It assumes that an entire project will be built and bundled at the same time. For example, we can't select a group of files, tag them, and migrate those files from one system to another. Tags are repository wide in SVN. Not all projects are creating whole apps from scratch and if your project is support only (like ours) svn can't do it.
We also looked at mercurial. Mercurial is much better than svn and I really can't see why anyone would choose svn over mercurial or git; however, it has the same limitation on file based tagging, so it is a no go also.
At the end of the day, we appear to be stuck with cvs. Knock it all you want, but it is the only open source app that is mainstream, integrated with our tools, and works with file based development. If I was working on a source tree that compiled and deployed the entire tree, mercurial would have been my first choice.
So, the moral of the story is that your project will dictate the scm used. Also, anyone considering svn should take a good look at git and mercurial - they are much better than svn since they are distributed and handle merges much more elegently.

I second Visual SVN Server. One-click install and you're good to go with Apache integration no less.

http://www.visualsvn.com/server/

Wow, thank you for this. Having been forced by clients to use VSS (Ouch!), ClearCase (Bigger Ouch!), and most recently TFS (apparently I'm not the only one who spent 2 weeks trying to set it up :-/ ), I have come to love SVN's simplicity, from the client side at least.

Now thanks to your post, and the many useful comments and links above, I'll be able to make a serious attempt at getting my own SVN server going for my projects.

Thanks again.

Jeff,

do you use typed dataset in vs2005? yes? Ok. Let's try to modify a typed dataset from 2 different programmer and the commit to subversion. The first, no problem. The second needs to "merge". Good luck! You need to merge 2 xsd, 2 xss and regenerate the .Designer.cs.
It's painful operation!

Fabrizio

>> Unfortunately, since Tortoise is a shell extension, setting changes may mean you need to reboot.
>> You can try terminating and restarting explorer.exe, but I've had mixed results with that.

After making changes to icon overlay in/ex(clude) paths, it is sufficient to simply kill the TSVNCache.exe. It will be started shortly, with the new settings.

"Give me a distributed VCS that doesn't use huge hex strings to identify revisions, works decently on Windows, and has Eclipse integration; and a sourceforge-like site supporting it, and *then* I might start looking at the distributed model."

Check this one: windows, gui, distributed, and doesn't use a hex number...

http://codicesoftware.blogspot.com/2008/03/going-distributed-with-plastic.html

Running through Apache, you get the option of securing your connections (https://someserver/repository), and surprisingly, you get the ability to authenticate SVN against your Windows domain, which you can't do if you set SVN up via svn:// (though you might be able to manage it with svn+ssh:// via Cygwin, though I've always found that protocol to be a bit slow).

We like subversion here,
but we have one serious issue - it has case sensitive storage. Visual Studio sometimes changes case of a file name, and later when you commit the project, the repository contains for example both test.txt and TEST.txt.

Is there a way to force case-ignorance into subversion?

thanks

Hi,
I have also written a small guide to install both the server and clients for SVN, using VisualSVN Server and Tortoise SVN client (free packages).

Please check my page:

http://fabianmejia.blogspot.com

If you're new to Source Control, or are trying to teach team members about it, I'd go with Mercurial. It allows you to completely ignore the "distributed" aspect of source control (which a centralized system by nature can't do) and concentrate on the "versioning" part, which is where you'll get the most immediate and obvious benefits. You can save the remote pushing and pulling for later, after they're hooked.

In short, it's easy:
http://tailguard.blogspot.com/2008/06/source-control-not-just-voodoo-anymore.html

A little late to the discussion here. But to solve people's issue with the .svn is easy. Just do an svn export to another folder. Keeps your development folder with the .svn folders, and gives you a clean distribution for deployment.

Hey Jeff

Great article - got it all setup and running by following it.
Thanks

make sure you don't leave any spaces at the front of the entries in svnserve.conf when you remove the pound signs or you'll get the "svnserve.conf:12 Option expected" error.

For my first time installing svn on Vista, I spent 15 minutes trying to get it working. Then I figured it out, Remember to open a command prompt as administrator when you get to the services part of the installation.

Hi Jeff,

Great intro article. Thanks for taking the time to write this. I got started up in about 1 hour... still not bad.

Thanks

Sub version.
Heard for the first time.
http://crackzsl.blogspot.com/
Winguard Blog.
http://winguard.blogspot.com/

The ordinary stuff is easy with SVN... but how do you merge your branch back into the trunk without losing your branch's revision history?

I had to use this syntax to create the service:

sc create SubversionServer binpath= "\"C:\svn\bin\svnserve.exe\" --service -r c:\svnrepos" displayname= "Subversion Server" depend= Tcpip start= auto

Even that didn't work for me, Geoff. It would have been very helpful if, somewhere in the very long discussion on this blog entry, someone had made Jeff fix the very bad escaping in his "run these commands" instructions (and made him prove that what he typed in actually works)

My biggest gripe with how-to's on the internet is how many of them DON'T WORK, even when every assurance is made that they should.

Two thumbs down.

Here's a free one-click way to install SVN on windows...
http://www.visualsvn.com/

This doesn't work under Vista home premium.

hi,
i'm totally new to SVN and need help..i'd be really grateful for any help offered! :)
i'm stuck at the part,
1)
what does svn do?

2)
set SVN_EDITOR=c:\windows\system32\notepad.exe
svn mkdir svn://localhost/myproject..
i get, " no repository found in svn://localhost "

2)
how do i get the branch/tags/trunk into my folder!
can't find them in any svn related folder and i'm really confused by the materials found online.

cheers!

Thanks just need the "sc create..." part.

@Miff
Just instaled on win7 so it shouod work on Vista. :)

Hi,
Firstly thank you, this post helped me alot :)
and I wanted to ask if it is ok with you that I translated this post to my language in my weblog.