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.
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. 
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.
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)
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 ;).
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/
1 Like
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.
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
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.
With respect, this seems years too late. 
http://svn1clicksetup.tigris.org/ solved this in September of 2005. Not to mention VisualSVN Server.
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.