Setting up Subversion on Windows

When it comes to readily available, free source control, I don't think you can do better than Subversion at the moment. I'm not necessarily advocating Subversion; there are plenty of other great source control systems out there -- but few can match the ubiquity and relative simplicity of Subversion. Beyond that, source control is source control, as long as you're not using Visual SourceSafe. And did I mention that Subversion is ... free?

This is a companion discussion topic for the original blog entry at:

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.

1 Like

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

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

how about

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.

I rue when “merge day” appears and everyone breaks each other’s code.

I watched the rest of Linus’ talk at . 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. :slight_smile:

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.

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

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 :slight_smile:

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.

1 Like

Has anyone tried any of the Visual plugins for Subversion?

“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.

@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.

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.

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