views:

181

answers:

9

What is the best way to share source across local machines?

I'm working on a cross platform project with an svn repository. I perform a checkout on one platform (perhaps osx), and make changes. I must then test my modified code on other platforms (xp, vista, ...) BEFORE checking it in. Manually copying files between machines or running everything from a network drive is a pain...what better options do I have?

+1  A: 

why don't you use svn still.. Before you switch to another platform, check in and tag the current version. Checkout and test it on the other platform. If you fail, just revert it.

Koray Balci
I would assume that other people are working in the current branch, though, and this might cause a race condition - someone might try to check in an update on top of his untested code.
Jonathan Schuster
@Jonathan So create another branch.
Adam Jaskiewicz
+11  A: 

You could also create a branch for yourself in SVN. Then you can check in to your branch, check out the branch code on all the test machines, and when you're satisfied use SVN's branch merge tool to merge all your changes saved in the branch back into the trunk.

Ryan
By definition, this is exactly what SVN is good for.
T Pops
A: 

Research platform-independent network disk mounts – something like sshfs. Check out the source on one machine and then mount that location over the network on the other computer.

Alternatively, run one operating system in a virtual machine on the same computer, and just share the files that way. Virtual machines like VirtualBox give you access to the host machines' file system through a network mount in a similar manner.

Schrockwell
+3  A: 

You might try creating a branch in the repository just for your own changes. Make your changes to the branch, commit the changes, then checkout the branch on the other platforms and test it. If everything works, merge the branch with the trunk.

David
AKA exactly what Ryan said above.
David
+1  A: 

I would say the best and easiest to manage (once up and running is to have a developement branch that automatically deploys to the testing environments and then when you are happy you can merge up to a release branch. Will take a while to setup but will save you SO much time in the long run.

It will also allow you to have things in test whilst you work on other items.

If you don't want to follow this then a simple shell script should suffice which you will have to run when you want to deploy.

caveman_dick
A: 

I think you're making a basic error here. The rule with SVN (and other adequate VC systems) is "check in early and often, just like voting." As @Koray says, check in the code, check it back out from the other machines and rebuild. Otherwise, you're risking your potential changes on the other machines not making it back, or needing to merge different change sets.

The trick is to make a tag for the most recent tested version, so you can revert to that paticular snapshot if you have troubles.

Charlie Martin
A: 

I would create a build script using a tool such as Ant to copy my checked out source to my set of different test machines over network shares. I would then proceed to test on each machine, but only make changes on my checked-out source - all changes are distributed to my test machines using the build script.

Once I am satisfied, I would commit my changes from the same machine I am building from.

tehblanx
+1  A: 

You could always try Git or some other DVCS, which allows you to share stuff without including the central server everytime.

Git allows you to push/pull (aka commit/update) to/from an SVN server too, but gives you more leeway on the side.

Marcus Lindblom
A: 

The basic issue is testing BEFORE checking in. That is exactly the problem. There is nothing wrong with checking in the code and then testing. The purpose of using source control is to allow rollback if something doesn't work.

I am also assuming from your post that your working on the project alone, so it would be even less of a problem. If your working in a team then create a seperate SVN branch to do development in and then merge with the main trunk when testing and development is complete.

Another option, use virtual machines.

Diago