New to SVN, How to Setup?

Question

I have a Windows 2003 Server with IIS, I installed VisualSVN Server on it.

I have two developers, who are going to use TortoiseSVN.

Since this is my first time ever setting up a SVN server I am kind of confused on how this will all work. The way I see it, each developer would have a copy of the repository on his or her local pc, would each person be required to have IIS installed on their PC as well to test their copies before checking out?

Should I create a testing folder on the server and then a production ready? It seems as if that would cause more issues with copies?

What would you do?

EDIT

I dont know what I was thinking, I forgot that VS has a built in IIS when you debug so the issue about setting up IIS on either client or server is now a non-issue. But I am confused, I imported the site into the repo, it said it was on revision 2 but I dont see any of the files in the repo folder. Do I create a virtual folder in IIS pointing to the repo that I created?

Answer 1

It depends on how you work. There are other discussions about folder structure and such which play directly into how you use version control.

Answer 2

No, each developer uses your repository, and checks out their own copies to do their work. They do not need IIS or svn, etc, installed on their systems.

I recommend reading up on the Subversion FAQ.

Answer 3

Uh, no, no local repositories. Setting up SVN is easy, well almost. You'll want to look for the svn windows installer and set it up on the server. You'll want to install Apache and then you'll have a little hurdle setting up the http.conf file to expose svn over http. There's a little complexity with setting up security so go with Windows Authentication, you'll need WebDav, google it.

Once that's done, any svn client can hit it and checkout a copy and work with SVN normally. If you get really stuck, comment here and I'll go get a copy of our install and config for you.

The good news is that it's rock solid, once you get it setup it'll run forever.

Answer 4

No, SVN server must be installed on a single computer. Each developer point at this computer and get locally (and eventually) a full copy or a partial copy of the repository.

You may also buy a book from O'Reilly about Subversion. Don't remember the title, sorry, but it helps me a lot.

All the best ! Sylvain.

Answer 5

"Pragmatic Version Control Using Subversion" and the SVN red-bean are the two sources you need to see.

Set up SVN on a single server and have all your developers point to it.

Answer 6

I've installed tortoise on the server and do Updates / Checkouts of the release website. Some people don't like checking in compiled code, but I like having the production compiled site in SVN.

If you use tortoise on the server, Do the initial checkout to the inetpub/website directory and then on rollouts you just need to update the directory using tortoise->update

Of course checkin to rollout is considered bad practice without first rolling out and testing on staging servers, but depends on your team size.

Answer 7

Your devs don't have a local repository, they have a Working Copy on their PC. Typically, this is the most recent version of the app with whatever changes have been made by the developers but not committed yet.

As this is a web app, then your developers will need some kind of web server locally to test it - this could be IIS, or Visual Studio's built in web server (although that does behave differently to IIS in subtle ways).

You said in a comment: "My problem is I dont want the devs to commit to the live site in case there was a bug.".

The devs commit to the SVN repository on the server: at some point you will want to export (aka 'publish') a copy from the latest version in your repository to your live site. In order to make sure this works, you can check out a specific version from the server, test it, and if it passes the tests upload it: devs will always check in code with bugs (even though it builds) as it's better to check code in frequently than build up lots of changes locally then commit them, as there are bound to be conflicts with work other developers have done.

Branching and Tagging are useful concepts here: when you have a version which is almost right, you 'branch' it away from the main 'trunk' of the source code tree, fix any issues in the branch (back-porting to the main trunk as required), then when you have a working version you 'tag' it (as version x.y.z) and upload it. This way you can always refer to the particular version of the code you have uploaded, which makes it a lot easier to identify bugs which turn up in production. As others have suggested, read the SVN documentation for more info.

Answer 8

No - your central server will maintain the repository. Your developers will get copies of the repository, make changes, and then commit them to your repository.

You actually have quite a few things to figure out if you want to do a successful deployment of subversion.

One really good article about setting up subversion on windows - http://www.codinghorror.com/blog/archives/001093.html

Answer 9

I have used the following resources for learning SVN:

http://www.polymorphicpodcast.com/shows/subversion/

http://www.dimecasts.net/Casts/ByTag/SVN

Found both quite good, and learning by watching can be easier especially for getting started.