Mercurial: Early Thoughts
We're using Mercurial as our source control system on the project I'm working on at the moment and since I've not yet used a distributed source control system on a team I thought it'd be interesting to note some of my initial thoughts.
One of the neat things about having a local repository and a central one is that you can check in lots of times locally and then push those changes to the central repository when you want everyone else to get the changes that you've made.
So far we've been pushing much more frequently than would usually be the case using something like Subversion. For example I checked in after doing some tidy up on unused references whereas with Subversion I'd probably have included that as part of another checkin.
It actually makes development more fun and reminds me of a kata I did while checking in almost every minute last year.
We're all still very much learning Mercurial but these are some of the commands that we've found ourselves using a lot so far:
To check if there are any changes to pull from the central repository:
hg incoming hg in
To check if we have any changes that we haven't pushed to the central repository:
hg outgoing hg out
To add any unversioned files and remove any missing files:
To remove a file from the repository and from the file system:
hg remove /file/name
To remove a file from the repository on the next commit but not remove it from the file system:
hg forget /file/name
To pull any changes from the remote repository and update your repository with them:
hg pull -u
This one only completely works if you don't have any changes locally on the files you're pulling in. Otherwise you'll need to do a 'hg merge' afterwards.
It seems like there's a lot more merging to do when using Mercurial than with Subversion which we're still getting used to but seems to be more natural as we use Mercurial more.
To undo committing a file locally:
hg rollback hg ci -X /file/to/not/commit -m"message and so on"
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)