Page 1 of 1
Multiple SVN on single machine
Posted: Fri Feb 13, 2009 7:35 am
by alex.barylski
There is a team of about 3-4 of us...there is no SVN in place and problems are starting to occur with overwrites.
SVN is the solution but the problem is, we each work off a Windows machine and the code is stored on an Ubuntu server which we all access via Samba.
I'm thinking I'd like to propose a SVN solution where we simply checkout into another directory on the Ubuntu server and access the code using something like:
http://domain.com/myproject
My only concern is the lack of separation of HTML from PHP and hardcoded URI's might make it difficult to setup a test environment. For instance the working environment would probably require each test environment to have hardcoded domains and sub-domains.
Cheers,
Alex
Re: Multiple SVN on single machine
Posted: Fri Feb 13, 2009 8:22 am
by VladSun
Setup your own DNS server with properly configured domain zone files

Then use this DNS server as a primary one on your workstations.
Also you may use SVN hooks to update the Apache web directory of the project after any of you has committed something.
Re: Multiple SVN on single machine
Posted: Fri Feb 13, 2009 10:09 am
by alex.barylski
Also you may use SVN hooks to update the Apache web directory of the project after any of you has committed something
This I think I understand...basically as I understand:
There would be a single repository which each of commited to at days end. Whenever this repo was updated the hooks would update the source tree which was used by Apache?
I'm not totally clear on how to go about setting up multiple checkout directories all on the same server as Apache and the repo.
Re: Multiple SVN on single machine
Posted: Fri Feb 13, 2009 10:30 am
by Eran
Checking out multiple working copies is the same as checking out - just to different directories.
I set up our repository using something similar to the recommended directory structure -
http://svnbook.red-bean.com/en/1.5/svn. ... ing.layout.
On our server we have 2 subdomains in addition to the main domain - dev.octabox.com, stage.octabox.com and
http://www.octabox.com.
Each of those subdomains is checkout of different directories in the repository (trunk / branches)
dev.octabox.com is our sandbox where different developers can play as they like. It is a checkout of the /branches directory from the main repository
stage.octabox.com is our staging environment where we test code before it goes to production - and this happens using a complete build script that also runs tests and sets permissions etc. It is a checkout of the /trunk directory
http://www.octabox.com is our production environment. It is a checkout of the /trunk repository
When we commit to the trunk, it runs a post-commit hook that updates the stage working copy. (the trunk)
Re: Multiple SVN on single machine
Posted: Wed Mar 04, 2009 12:35 pm
by alex.barylski
Here is the problem as I understand it now.
1. We have two servers (Live and Test)
2. There are 5+ developers all actively working on the same source base (collisions are a daily event)
3. The Test code is copied over to the live server every few days
I want to setup SVN to prevent collisions and to bring some accountability to the mix of developers.
Ideally I thought I might be able to setup several working copies on the test server while using the repo as the code base for the test server itself. Problem is I wanted everyone to be able to checkout at the start of day, work on the code running in their own environment, the commit at days end and merge what was needed.
Now I find out the developer has code in a framework.inc.php that basically checks the domain and if it's not the Internet domain assumes the local development domain (xxxloc.com or xxxlive.com). To make matters worse, SSL is being used and the developers only registered the two previous domains with the SSL cert -- so I can't even setup quasi domains and map those to the appropriate sub-directory housing each of our own working copies.
So now I'm thinking...perhaps what I do is have everyone checkout code, make the change and commit back to the repository -- merging at that point in time. This is pretty nasty and I'm not sure I like it as everyone accesses the live test server as is using Samba, so getting them to switch to TortoiseSVN or similar now will be like pulling blood from a stone.
Any suggestions?
Re: Multiple SVN on single machine
Posted: Wed Mar 04, 2009 1:08 pm
by Eran
I'm not sure what you mean by checking out code every day. You check out once - this creates a working copy. You then run updates and commits as necessary.
In regards to having hard coded URLs that is a design issue and can be resolved if you are aware of it. I have a configuration file that sets up my environment, and it has something similar to:
This sets up the base directory for the application, regardless of what server it's at. I used to do the same for the http path:
Code: Select all
$baseUrl = substr($_SERVER['PHP_SELF'], 0, -9);
However ZF does this automatically for me so there is no need anymore.
I also set a base directory tag for the HTML document, to avoid using those constants more than I have to:
Code: Select all
<base href="http://<?php echo $_SERVER['HTTP_HOST'] . $baseUrl .'/'; ?>" />
This is useful for typing image and script paths. For actual links I use the $baseUrl I mentioned above.
Re: Multiple SVN on single machine
Posted: Thu Mar 19, 2009 2:44 am
by Chris Corbyn
I don't understand what you're on about
SVN is designed to manage mutliple developers on the same code base out-of-the-box. Conflicts are something that crop up occasionally and SVN makes the developer aware of them so they can fix it (you can't commit code with a conflict in it).
So I'm failing to see what you're looking to achieve? You should never have separate repositories, otherwise conflicts will be even more of a problem and harder to resolve.
PCSpectra wrote:Problem is I wanted everyone to be able to checkout at the start of day, work on the code running in their own environment, the commit at days end and merge what was needed.
This is generally a bad idea with any type of version control system. Your commits should reflect a small subset of changes... not a day's work (which may not even be complete). Commiting and updating frequently also minimizes the conflict problem you're facing. Say you make a change to two lines in one class. And that change fixed a bug. You do a quick "svn up", make sure it still works, and then you commit. Then onto the next change.
Keep your commits atomic and fetch updates frequently.