How do you setup a shared Working Copy in Subversion

Question

I still very new using Subversion.

Is it possible to have a working copy on a network available share (c:\\svn\\projects\\website) that everyone (in this case 3 of use)

Answer 1

I know this is an old thread, but I found it because I'm trying to do the same thing.

I don't think this problem can be solved with subversion, though I've tried on multiple occasions and I think the need is completely legitimate.

The use case that comes up repeatedly for us is complicated configuration files that are maintained outside of an application.

A good example might be apache httpd.conf files. They're complicated and we want to track changes to the files. We don't want everyone to use "root" because then we can't track who did what.

Mercurial can do this:

Mercurial Multiple Committers

Answer 2

Working copies are meant for each user to have his own. And the repositories are shared. Only the person who checked out the WC can commit changes from it.

Answer 3

Maybe you could look at something other than subversion if you dont want a server, like a distributed VCS (Bzr, git, and mercurial are popular these days) or you should look at subversion hosting services.

Sharing a single working copy is not recommended. That really defeats the purpose of version control. Please don't do that.

Answer 4

I think you're selling your team short. Non-devs can easily learn to use SVN, especially with something like tortoise. If you're gonna go through the trouble of setting up SVN, then just give everyone a separate login and let them work on their own local working copy. Do a quick and dirty CruiseControl automated build to pull from SVN to create the staging site content. It's just a little more work and the result will be so much nicer.

Answer 5

I know this is an old question/wiki, but a solution that occurred to me is as follows.

The problem could be restated as follows: How can we use a real source control system (like SVN), and still allow non-technical designers to enjoy the same save-preview-save-preview cycle that they've come to know and love?

Points:

• In order to realize the full benefit of SVN, each user needs to have their own working copy. That's just the way it is.

• If you've still got classic ASP (NOT .NET) in your app, a lightweight local server like Cassini won't do the job.

• It'd be preferable for the user to not have to install or learn to use an SVN client like the (admittedly-simple) Tortoise.

My approach:

• Create a branch in SVN for each user

• On each client, provide a mapped drive to a user-specific working directory on your dev server. They will use FrontPage, Expression, SharePoint designer or whatever to make their changes here.

• In IIS on the dev server, create a user-specific website (for example, alice.www.mysite.com or bob.www.mysite.com) with a user-specific host header. They will browse the site through this URL to see their changes. This also allows them to show their changes to others before merging it into the trunk.

• Using CruiseControl.NET, provide tasks to check out, update, add and commit changes for each user's branch. Figure out how to make this so that each user can only see their own tasks.

• Using CruiseControl.NET, create a task that will merge their changes into the trunk

• Using CruiseControl.NET, create a task that will update the real dev site (dev.www.mysite.com) with the merged changes. This site will show everyone's work combined, and acts as a staging and debugging area. If you are using a WAP, you'll want this task to trigger a build as well.

Sounds like a lot of steps, but it's really pretty simple. Create branches, map drives, set up new IIS sites and let them go crazy.

Under the covers, this is exactly the same as giving them a local IIS install and letting them commit their changes with SVN whenever necessary, just as developers do. The difference is that their working copy is on a server, IIS/Cassini doesn't have to be on their box, and they'll use a web interface to perform SVN actions like commit, update, etc.

Good luck!

Answer 6

You are meant to have your SVN repository, and each user (with their own username and password to access the SVN repository) should check out their own working copy.

It is possible to do this on a single PC (is that your problem, PCs with multiple developers sharing it?) by having different PC user accounts and having the people check out into their own account, or even by sharing a PC user account and having the people check out into a different working folder. I don't think this is particularly neat or nice, and if a company can't afford a PC per developer these days then it is hardly worth working for!

I recommend:

1. Each employee has their own working copy on their own PC.

2. There should be an ANT or Maven or similar build script that will allow a developer to build and deploy from their working copy onto the development web server so they can see how it is. This could be simple as "copy files to this shared location".

3. As each employee has their own SVN username/password you can see who made which change, and lock people out when they leave the company.

4. This might create a process that a designer has to follow rather than the anarchy you have currently, but if it takes any of them more than half a day to pick up SVN and how to run a build script to deploy to the development web server then you've got bigger problems.