April 5, 2008
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?
Allow me to illustrate how straightforward it is to get a small Subversion server and client going on Windows. It'll take all of 30 minutes, tops, I promise. And that's assuming you read slowly.
The first thing we'll do is download the latest Subversion Windows binary installer. At the time of writing, that's 1.46. I recommend overriding the default install path and going with something shorter:
Note that the installer adds
c:\svn\bin to your path, so you can launch a command prompt and start working with it immediately. Let's create our first source repository, which is effectively a system path.
svnadmin create "c:\svn\repository"
Within that newly created folder, uncomment the following lines in the conf/svnserve.conf file by removing the pound character from the start of each line:
anon-access = none
auth-access = write
password-db = passwd
Next, add some users to the conf/passwd file. You can uncomment the default harry and sally users to play with, or add your own:
harry = harryssecret
sally = sallyssecret
As of Subversion 1.4, you can easily install Subversion as a Windows service, so it's always available. Just issue the following command:
sc create svnserver binpath= "c:\svn\bin\svnserve.exe --service -r c:\svn\repository"
displayname= "Subversion" depend= Tcpip start= auto
It's set to auto-start so it will start up automatically when the server is rebooted, but it's not running yet. Let's fix that:
net start svnserver
Note that the service is running under the Local System account. Normally, this is OK, but if you plan to implement any Subversion hook scripts later, you may want to switch the service identity to an Administrator account with more permissions. This is easy enough to do through the traditional Windows services GUI.
Now let's verify that things are working locally by adding a root-level folder in source control for our new project, aptly named myproject.
svn mkdir svn://localhost/myproject
It's a little weird when running locally on the server, as Subversion will pop up a copy of Notepad with a place for us to enter commit comments. Every good programmer always comments their source control actions, right?
Enter whatever comment you like, then save and close Notepad. You'll be prompted for credentials at this point; ignore the prompt for Administrator credentials and press enter. Use the credentials you set up earlier in the
conf/passwd file. If everything goes to plan, you should be rewarded with a "committed revision 1" message.
svn mkdir svn://localhost/myproject
Authentication realm: <svn://localhost:3690>
Password for 'Administrator': [enter]
Authentication realm: <svn://localhost:3690>
Password for 'sally': ************
Committed revision 1.
Congratulations! You just checked your first change into source control!
svn:// as the prefix to our source control path, which means we're using the native Subversion protocol. The Subversion protocol operates on TCP port 3690, so be sure to poke an appropriate hole in your server's firewall, otherwise clients won't be able to connect.
Now that the server's good to go, let's turn our attention to the client. Most people use TortoiseSVN to interact with Subversion. Download the latest 32-bit or 64-bit Windows client (220.127.116.1137 as of this writing) and install it. The installer will tell you to reboot, but you don't have to.
Now create a project folder somewhere on your drive. I used
c:\myproject. Tortoise isn't a program so much as a shell extension. To interact with it, you right click in Explorer. Once you've created the project folder, right click in it and select "SVN Checkout..."
svn://servername/myproject/ for the repository URL and click OK.
Tortoise now associates the
c:\myproject folder with the
svn://servername/myproject path in source control. Anything you do on your local filesystem path (well, most things-- there are some edge conditions that can get weird) can be checked back in to source control.
There's a standard convention in Subversion to start with the "TTB folders" at the root of any project:
Because Subversion uses regular directory copies for branching and tagging (see Chapter 4, Branching and Merging), the Subversion community recommends that you choose a repository location for each project root -- the "top-most" directory which contains data related to that project -- and then create three subdirectories beneath that root: trunk, meaning the directory under which the main project development occurs; branches, which is a directory in which to create various named branches of the main development line; tags, which is a collection of tree snapshots that are created, and perhaps destroyed, but never changed.
Of course, none of this means your developers will actually understand branching and merging, but as responsible Subversion users, let's dutifully add the TTB folders to our project. Note that we can batch up as many changes as we want and check them all in atomically as one unit. Once we're done, right click the folder and select "SVN Commit..."
In the commit dialog, indicate that yes, we do want to check in these files, and we always enter a checkin comment-- right? right?
You'll have to enter your server credentials here, but Tortoise will offer to conveniently cache them for you. Once the commit completes, note that the files show up in the shell with source control icon overlays:
And now we're done. Well, almost. There are a few settings in Tortoise you need to pay special attention to. Right click and select "TortoiseSVN, Settings".
- See that hidden ".svn" folder? These folders are where Subversion puts its hidden metadata schmutz so it can keep track of what you're doing in the local filesystem and resolve those changes with the server. The default naming convention of these folders unfortunately conflicts with some fundamental ASP.NET assumptions. If you're an ASP.NET 1.x developer, you need to switch the hidden folders from ".svn" to "_svn" format, which is on the General options page. This hack is no longer necessary in ASP.NET 2.0 or newer.
- I'll never understand why, but by default, Tortoise tries to apply source control overlays across every single folder and drive on your system. This can lead to some odd, frustrating file locking problems. Much better to let Tortoise know that it should only work its shell magic on specific folders. Set this via "Icon Overlays"; look for the exclude and include paths. I set the exclude path to everything, and the include path to only my project folder(s).
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.
And with that, we're done. You've successfully set up a Subversion server and client. A modern client-server source control system inside 30 minutes -- not bad at all. As usual, this is only intended as the gentlest of introductions; I encourage you to check out the excellent Subversion documentation for more depth.
I find Subversion to be an excellent, modern source control system. Any minor deficiencies it has (and there are a few, to be clear) are more than made up by its ubiquity, relative simplicity, and robust community support. In the interests of equal time, however, I should mention that some influential developers -- most notably Linus Torvalds -- hate Subversion and view it as an actual evil. There's an emerging class of distributed revision control that could eventually supercede existing all the centralized source control systems like Subversion, Vault, Team System, and Perforce.
I'm skeptical. I've met precious few developers that really understood the versioning concepts in the simple centralized source control model. I have only the vaguest of hopes that these developers will be able to wrap their brains around the vastly more complicated and powerful model of distributed source control. It took fifteen years for centralized source control usage to become mainstream, so a little patience is always advisable.
Posted by Jeff Atwood
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).
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.
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.
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
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.
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:
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...
And you wonder why people choose SourceSafe over subversion??
Please do not use SourceSafe.
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 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/
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
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.
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:
sh: c:windowssystem32notepad.exe: command not found
svn: system('c:\windows\system32\notepad.exe svn-commit.tmp') returned 32512
/\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.
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=)
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.
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.
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.
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.
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!
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...
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?
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:
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:
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.
Great article - got it all setup and running by following it.
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.
Great intro article. Thanks for taking the time to write this. I got started up in about 1 hour... still not bad.
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
This doesn't work under Vista home premium.
i'm totally new to SVN and need help..i'd be really grateful for any help offered! :)
i'm stuck at the part,
what does svn do?
svn mkdir svn://localhost/myproject..
i get, " no repository found in svn://localhost "
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.
Thanks just need the "sc create..." part.
Just instaled on win7 so it shouod work on Vista. :)
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.
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.
"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.
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.
SVN supports locks. And recommends these for binary files. http://svnbook.red-bean.com/en/1.5/svn-book.pdf
Linux is subdivided into "maintainers" who manage areas of the product so their intrinsic management hierarchy implies merges will be slight. Operating Systems are very complex but also very well understood. Some random product with scores of developers and normally very weak formal software engineering processes will not work will with GIT or any other source control system unless commits to the central repository are daily or more often. Of course, the real solution is to replace the posers with real software engineers; but we know management wants to pay peanuts so we have to use the appropriate herd control.
Thanks for the tutorial. Works perfectly!
If you run Subversion server on Windows server then you can take a look at http://www.coretica.com/svnmanager/index.aspx . Svn Manager for Windows is a web-based Subversion management tool and very decent. You can also browse branches and tags in the repository. It does not support any write operations.
For this to work with newer setups (Windows 7, probably Vista), you will have to include the --listen-host parameter with 0.0.0.0 (--listen-host 0.0.0.0).
I found that if I didn't include this, I could only connect using svn://localhost/ and I couldn't even use svn://127.0.0.1/.
On other machines I got the message that the connection was actively refused. Quite annoying to go through the series of steps... services, firewall, router, other machines, proper interface binding, etc etc.
Hopefully this helps someone!
The links in the base post for downloading Subversion are a bit stale. The community members who were keeping regular Subversion builds on Tigris have stopped doing that, because there are now professionally built and QA'ed (and still free!) binaries available, such as those on
Also: the process of setting up and administering a server just got immensely easier, with the release of CollabNet Subversion Edge, also available at the above URL, and free: a 1-click install, and a web admin console.
I get to the part where I try to commit my first project to svn, at which point I am not getting the prompt for authentication and I get the following error.
C:\Users\Ryan>svn mkdir svn://localhost/myproject
svn: No repository found in 'svn://localhost'
svn: Your commit message was left in a temporary file:
I've gone through the instructions twice step by step to make sure I didn't miss something and I get the same results. Please help!
I was following this and getting the following when trying to start the service:
"The service is not responding to the control function.
More help is available by typing NET HELPMSG 2186."
Looks like this was because I did not follow the advice in the article and choose install without spaces. So, I chose:
In this case you need to use escape characters to specify the service setup, namely:
sc create svnserver binPath= "\"C:\Program Files\Subversion\bin\svnserve.exe\" --service -r c:\svn\repository" displayname= Subversion depend= Tcpip start= auto