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.
1 Like
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.
Ruby on Rails Moving Source Repository to Git:
http://blog.wired.com/monkeybites/2008/04/ruby-on-rails-m.html
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
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?
-
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.
-
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.
1 Like
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.
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?
1 Like
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
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.
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