How to set an svn repository path to a server path?

Question

Someone on SO said setup source control, it takes 5 minutes. It's taking ages, it's fiddly and a pain in the arse! And I don't get the workflow

Anyway. I have svn installed on server1. Server1 is also used to store all of our existing source code and projects, which have now been added to their respective repositories on server1. We have three developers working on machines 1, 2 and 3. When we open the working copy projects on server 1 in Visual Studio (with VisualSVN), the filepath to the repos is file:///d:/foo of course when you commit you get an error message that says file:///d:/foo cannot be found because it's on the server not the machine.

How do you make it point to file://\server/d$/foo?

I have tried

svn switch --relocate file:///d:/foo file://\server/d$/foo

Doesn't work

The workflow part that I can't get my head round is this. If I check out a working copy of a class project and compile it. Do I move the new dll from my working copy to production? Or do I check the dll back into source control, and then move it from source control to production? What if multiple projects use the dll, do I take it out of source control to a folder somewhere that all the projects look to, or do I copy it into the bin folders of all of the projects. Headache

EDIT: Thank you for all of your input, I will persevere with this one!

Answer 1

I suspect that your use of UNC names so that you can have a network based repo while still using a file:// scheme is the problem here. There should be an SVN server on the repo hosting machine. This would be would not be contacted using a file:// scheme.

With regards to checking in compiled output, in short, don't. What is in subversion should be buildable by each client from scratch. Compiled binaries have no place in a subversion repo, unless (perhaps) they come from a 3rd party and are essential to the build.

"What if multiple projects use the dll, do I take it out of source control to a folder somewhere that all the projects look to, or do I copy it into the bin folders of all of the projects"... no answer. Sorry.

Answer 2

Yes, Source Control only takes minutes to setup, however, understanding how it works is the key.

In order to answer this it's probably best to explain how Source Control works and what you should expect to get out of it.

The book http://svnbook.red-bean.com/ (which you can read directly on line) has a fantastic explanation as to how it might work. The first couple of chapters is all you really need to glance over to get to grip with the basics.

Once you've got to grasp with the basics outline in the book, it should become obvious where you are going wrong with your implementation.

Answer 3

The SVN Book recommends that you do not use the file:// protocol for multiple users

Choosing a Server Configuration:

Do not be seduced by the simple idea of having all of your users access a repository directly via file:// URLs. Even if the repository is readily available to everyone via a network share, this is a bad idea. It removes any layers of protection between the users and the repository: users can accidentally (or intentionally) corrupt the repository database, it becomes hard to take the repository offline for inspection or upgrade, and it can lead to a mess of file permission problems (see the section called “Supporting Multiple Repository Access Methods”). Note that this is also one of the reasons we warn against accessing repositories via svn+ssh:// URLs—from a security standpoint, it's effectively the same as local users accessing via file://, and it can entail all the same problems if the administrator isn't careful

Answer 4

Nick:

Hang in there. Don't abandon source code control! Believe me, the learning curve you're riding now is going to pay off in spades down the line.

Re: your workflow issue, you're running into the question of how you build your software. There are a lot of methodologies here that you can use, but the basics are this. When you compile your app, make sure your artifacts (.exe's, .dlls, etc) are marked with svn:ignore (in Tortoise, you just say "add to ignore list"). That will keep SVN from checking in your builds. You don't want your build artifacts checked in from developer copies because it takes up a lot of space, and it creates a lot of conflicts.

You have a couple of options, but I'll make a suggestion for your workflow based upon what you've told me:

Build your DLL outside of source control. In SVN, set up a directory for your "released" code -- for me, it's a directory called "releases" under my project. Then, when your DLL is tested and verified, give it a version number and check it in to your "releases" section. Tell your developers that there is a new version of your shared DLL that they can use, and let them know what the changes are. They can then pull down your DLL at will and integrate it into their code.

Once you get comfortable with SVN (it will happen!) you can move on to using stuff like Hudson or CruiseControl.NET, which sit on your network and monitor SVN for changes. When they detect a change, they automatically build your software according to how you specify it. This makes all of this copying around business totally automatic. Even without CCNET, you can make a "build file" using nAnt or MSBuild (I personally use MSBuild) which will do all of this copying stuff for you according to a methodology you choose, so you won't have to be doing all of this manual stuff every time you want to make a build.