SVN: Multiple users, single working copy?

I know this isn’t the ideal setup but its the way we’re using right now:

The repository is checked out to the website’s dev site root (i.e. /var/www/html). Code is modified and commited here. It’s easy because you can make your changes, refresh - and see that change instantly. Not exactly possible if we all check out locally or something…

We’re using TortoiseSVN and it seems that when we commit, it changes the properties of the entries file inside of .svn to owner of the person committing.

If another person makes a change to the same file and tries to commit it, it fails.

Surely/hopefully there is SOMETHING we can do to deal with this?

Thanks!

Yes, use Subversion the way it’s meant to be used, with separate working copies. You can all refresh and view your changes instantly by running apache on your personal computers, and SVN UPDATE the copy at the host when you’re satisfied.

Why use SVN then if you are not using it for what it was designed to be used for? Having all your developers share a working copy is where all the problems stem from non version control systems. Version control was created to solve those problems!

What about when I need to show someone something prior to committing? Maybe it needs review or we collaboratively need to figure something out?

I can’t give them a URL to view the file or anything like that…?

How would you do that with the setup you want? The changes you’re making that you might not want to keep are being done on the live site!

Your computer is connected to the internet, you can show them using your IP address instead. Or you can copy your files to a temporary directory on your server.

Or you can commit it, everyone presses their update button, and they can see the changes on their own computers and you can continue collaborating. If you decide against the change, you just roll back. That’s why you have version control, so that you can go back to a previous version.

no… it is the dev site. Any changes are “instant” on the dev site. Commiting saves that copy to the local repo. We then use unison to push changes to live site.

You only picked at that point to ignore the rest of the relevant answers? (:

I have everyone working on the same repository get an e-mail whenever a change is committed so we all know to update to see the latest work. That way you don’t have to shoot an IM around to everyone saying “just committed”.

Just to reiterate what was said. If you are not using SVN for the reason it was created, why even use it? You would be better off not using SVN if this is the setup you want to have. Otherwise, good chance to rethink your development process.

Your current method you’ll run into this problem: http://svnbook.red-bean.com/en/1.5/svn.basic.vsn-models.html#svn.basic.vsn-models.problem-sharing

I am warming up to the idea of separate local copies, and I DO understand that’s the way it’s supposed to work…

Perhaps the issue I am seeing are things like (we use PHP):

  • We have define’s that specify document paths and whatnot… if we have a local copy that path isn’t the same (for starters, we’re on windows… dev server is linux)
  • We may have 10 different websites/subdomains/etc. We may have things like “partner.sitepoint.com”, which would display a different “skin”. When we’re on our own local copies its even more difficult to set up all these domains/subdomains and then share them across all developers
  • Whenever we add a new domain/subdomain/vhost/rewrite/change some other config… it has to be done on live, dev, then every developer’s computer… when branching out to having it on every developer’s computer… seems like a good spot for problems to creep up…
  • I have more concerns, just not off the top of my head…

As everyone else are saying, start working with SVN the way it is supposed to be used.

None of your conserns are valid ones. To be honest it sounds like your not liking the advice you received and are arguing against it.

To solve your config file problems, what we usally do is at the end of the “application” config file we include a new config file which we tell SVN to ignore when updating. That way your config settings will override those of the config file. If you set up a registry, just comment out the code in the real config file, its not used anyway and setup the dev server with a ignored config file as well. Of course this “ignored config” file is removed as soon as the development is finished, or the application is deployed

Doing it that way would take care of all of the issues you mentioned.

For the sub domains, if you require them to use them directly you can set them up in the host file and at the webserver, so they are directed there instead of the real site.

In further research I’ve come to a solution which I think I like best and could work well.

we would have “dev.site1.com” which is our dev site… or maybe the “staging” site, the version that syncs with our production.

Then we may have “developer1-dev.site1.com”, “developer2-dev.site1.com”, etc. for each developer. These VHosts would point to separate folders where each developer has their own working copy on the same dev server.

I think this could work… but we have ~10 domains, at least 3 developers… thats 30 new virtual hosts off the bat… what if we have another developer? or another site? Just seems like it could become a mess quickly… maybe not? Does that part even matter?

In this setup, I suppose each developer would commit, then we’d have to svn update the “dev.site1.com” checkout to see the final pre-production version?

(Side note: When you use svn update, does it set permissions of any updated files to that person, meaning any other developer would be unable to update that dev copy should the file change later? We’re using tortoisesvn)

Thanks everyone. Part brainstorming/part annoying myself (and you guys too I guess! sorry :()

The issues you are referring to stem from your system. Hardcoded paths well that is easily fixed by coming up with a more portable and dynamic solution. There is no reason why you should not be using portable path structures.

In my opinion you are making this overcomplicated by thinking each and every single developer needs to have an exact match setup to test on. Does every developer need to have a full blown domain name setup to test their code? If they do that is a problem that needs to be fixed (i.e. don’t use hardcoded domains).

Here is my advice. Leave the developers alone when it comes to software, servers, domains, and configuration. Let them come up with their own system that works for them. If your system requires everything to be an exact match, you are doing things wrong (IMHO).