thanks! man really interesting and educating article.
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.
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!
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.
- 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.
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/
Source_Control = âYAWNâ
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.