We recently decided to start using SCM software (yes we probably should have a long time ago) and we’ve decided to try Mercurial. From what I can find it supposedly plays better w/ Windows than Git does. We’re also planning use TortoiseHG instead of the command line, as that’s what we’re more comfortable with. I’m still very early in my learning, and I have a question I keep finding conflicting answers on.
We have an apache-served PHP site. We plan on putting each developer’s working copy on a different port until a time in the future when we can properly virtualize the server (one per developer). We’d like to keep a branch/tag/something for the “stable” build while we continue new development. Of course whenever there is a bugfix, we want to push that immediately, but we also want to merge it into the dev branch.
I’ve heard from some that we should clone the repo, do our changes in the clone, then merge it back in when done.
I’ve also heard we should just use branches, and merge the branch back in when done.
In the repository case, what do you do about apache? It’d be a pain to have to reconfigure it to point to a different directory each time you added new functionality…
Thanks for any light you guys can shine on this. I appreciate the help!
How do we go about this?
[edit]
Also, what are “shelve” and “patch” in regards to HG? Double thanks.
In a distributed revision control system, there’s no central server, each “clone” has a copy of the whole repository. Changes are made in the local repo, and later changesets are pushed to other ones (or pulled from them). So, in practice every clone is a branch, and every “commit” is a merge.
I’ll suggest an example of workflow below. For a more in-depth explanation of the things I wrote, please see this article (Edit: actually I meant this one, about Release Management, but the other one is useful too…) and this short Mercurial overview.
Suppose you have a “main” repository, that will contain all the up-to-date info from all developers. You can clone it (once) and create a “production” repository. After that, update it to the latest stable revision (which should’ve been marked using a tag).
You can also clone it again for each developer (reiterating: you only clone once), and have them work independently from each other. They can commit at will (since a commit only affects the local repository) and ideally should only push changesets to “main” when they’re stable. They can also pull changesets from other developers, but it’s up to them to perform a merge immediatly or not. When the “main” have a stable release, it should be tagged as such and the “production” can pull and update to that revision.
If a bug is spotted in the production version, any developer can: a) commit (or shelf) their current working dir; b) update their working dir to the same revision “production” is running; c) fix the bug, commit and push the changes; d) update again to where he left and continue working normally. The new changeset will be available for “production” to pull and update, and also for every developer to merge it into their current revision.
As for things that are specific to each working copy (port number, database instance, etc), you should store them in a separate configuration file, and have this file be ignored my Mercurial. This way, even when changing versions those values will remain the same for each individual developer and the production instance.