Version control; choices, choices, choices!

Question

Our setup as follows:

We have a local development server running Ubuntu, with a setup to mirror that of our live host. Each developer works on a Windows machine and accesses the files from the local dev server.

The projects in question are a number of websites built in PHP. Seeing as there are no good reasons not to use version control, we intend to get either SVN, Git, Mercurial or something else up and running on the server.

The question is, how do we do that but commit changes to it from the Windows machines, and how do we check out a finished area of a site (project), or a site as a whole, to upload onto the live (remote) server?

Answer 1

Why use SVN:

• Mature codebase
• Mature GUI tools on Windows (if your team likes them): TortoiseSVN
• Shallower learning curve (esp. if you've already used CVS)
• Sparse checkouts

Why use git (probably applies to mercurial too):

• Easier branching and merging
• Developers can interact with their own local repository without needing to contact the "master" repository
• Can work with upstream SVN or CVS repositories (but if you have a choice, I'd still use git upstream if developers are using git)
• "Good enough" Windows GUI tools (TortoiseGIT may actually be as good as TortoiseSVN now...haven't looked at it in a year or two).
• More powerful commands

One way to handle your use case is: - Each developer has their own private git repository - Developers push code changes to the dev server's repository when they're tested and ready for production use. - The live server has a checkout that's either updated on a regular schedule, updated manually, or updated by a commit hook on the dev server's repository (when commit, "ssh live.server.com (cd /my/dir ; git pull origin HEAD)").

This procedure could be adapted for SVN just as well, but the private repositories would just become checkouts.

Answer 2

Windows machines should be able to connect to the change-control server, no problem, using your client of choice (for instance, TortoiseSVN for Windows).

To do automated builds from your source repository, you can use some sort of Continuous Integration (CI) software. I'm not familiar with any of those products for the LAMP stack, but I'm sure there are many. And, if it's PHP for the web, you don't really need a build, so much as you need some sort of automated copying :-)

Answer 3

Unless I've misunderstood your question...

Each of the source control providers you have mentioned has a windows version, or works under cygwin, and so should work under windows exactly how they would under *nix - hence you should base your decision on what source control provider to use using the same criteria as you would normally.

Answer 4

How you set things up will depend a little bit on which source control software you choose.

I would set up a central repository on an internal server. This is required for svn, and gives you a canonical location to pull changes from if you're using git or hg.

Developers can checkout / clone the repository to their local machines and commit / push changes back. I would suggest using branches to distinguish between production code, and development code.

To deploy to the web site, you'd have a process that checks out from the central repository, updates to the production branch or tag, and then copies the files to the live server.

The exact details depend a lot on which version control system you use.

Answer 5

Subversion would work wonderfully. We have Subversion running on a linux machine and all of our development work is done on windows machines. 90% of the time we check projects in and out through the IDE (usually subclipse within Eclipse) and the other 10% of the time we use TortoiseSVN either of which will work fine.

You can commit changes to the repository through the IDE or Tortoise. You can tie in a continuous integration server with the repository to automatically build the project when you commit a code change to the repository.

Answer 6

I think the easy answer to your question is: These are not challenges. This is just how it works.

We use SVN here. Most of the developers work on Windows but our test group uses Linux and our production servers are Linux.

Developers check out from the SVN repository using the SVN plug-in for Eclipse. I've also checked out to Windows using TortoiseSVN and the SVN command line. When we're ready to deploy to one of the test or production servers, we simply check out from SVN on the appropriate server, compile, and we're done. With PHP you don't even have the compile step.

For playing around stuff I do at home -- well at home it's all Windows, but I use the command line SVN for administration, and then Subcommander to do workstation stuff.

Answer 7

We're using Subversion with TortoiseSVN. It works well. The last time we looked Git (six months ago?), the Windows tools were not there yet. Perforce (http://www.perforce.com) is the best commercial solution I've used.

Make sure you understand the differences of distributed revision control (Git) vs. Subversion and other traditional revision control systems. They're not the same.

GitSvnComparison Git For Designers

If you are working on PHP sites, you could create tar files of the repo and ship them to a test server for testing. Once you've verified the site is working, you could push that tar file to the live site.

Answer 8

If you want to work from Windows, I would also recommend to take a look at Bazaar, which has nice UI tools across all platforms (including Windows). One nice thing about it is that you can easily set up a tracking branch and still work locally offline/branching locally, which is kind of a hybrid distributed/centralised model. It might sound quite weird at first, but it's actually very useful if your team is small. You could always use the central version for your dev server, and tag/mirror from it to the live site; while each of your developers works on local copies and pushes to the dev server.

Answer 9

Mercurial would be a great fit. With the developer machines being Windows-based, you get better support and tools than git, yet end up with a more flexible system than subversion.

On our setup, we serve the repositories via apache with mod_wsgi, which was easy to setup, and has served us great.

For the deployment, I'd advise looking at the mercurial hooks if you want it done automatically.