With Mercurial, I have to be constantly conscious about whether I’m in the right branch, doing the right thing. If you’re working with Mercurial, TortoiseHg and command line are really your only sane options. Alternative Mercurial frontends are both trash, and an unbelievable pain to set up. Number one, I want my VCS features to be available from the command line and front-end both. This is apparently a problem the Mercurial developers are still puzzling over.Īctually there is one tool that’s solved this the way you would expect: TortoiseHg. Apart from the branching suggestions, there’s not one but half a dozen extensions to handle this problem, all of which have their own quirks and pretty much all of which involve jumping back into the VCS frequently. Oh but wait, how about the extension mechanism? I should be able to patch in whatever behavior I need, and surely this is something that bothers other people! As it turns out that definitely the case. So now I have to stop and think about whether I should be branching every time I make a tweak somewhere? Should be no problem, since branching is such a trivial operation in Mercurial. The idea with Mercurial is, I think, that you simply produce new branches every time you do something like this, and then merge back together. These changes are independent and shouldn’t be part of the same check-in. (Mercurial fans freely admit this is a bad way to work with it.) Within each project, I usually wind up making a few sets of parallel changes. When I’m working on something, I usually have several related projects in a repository. My take is that this is a stupid restriction that makes development unpleasant. The basic idea, I guess, is that somebody got really frustrated about forgetting to check in changes and decided this was the solution. This is an incredibly awkward design decision. If your code is in c:\code, when you issue the hg commit command, you can be in c:\code or in any subdirectory and it has the same effect. Whereas, in Mercurial, all commands always apply to the entire tree. You see, I have one gigantic problem with Mercurial, and it’s summed up by Joel: Basically Mercurial’s configurations are a headache. Setting up extensions is similarly a pain in the neck. Yes, because what I’ve always wanted from my VCS is for it to be a hassle every time I move to a new machine. For that you open the file ~/.hgrc with a text-editor and add the ui section (user interaction) with your username: The Mercurial guide starts with this as your very first step:Īs first step, you should teach Mercurial your name. Mercurial’s site has a Windows installer ready to go that sets everything up beautifully. Armed with that knowledge, I began looking at what’s involved in transitioning from Subversion to Mercurial. Say what you will about Joel - it’s a concise and coherent explanation of why distributed version control is, in a general sense, preferable to centralized. I was additionally spurred by reading the first chapter of HgInit, an e-book by Joel Spolsky of ‘Joel on Software’ fame. I started with Mercurial, because I’d heard anecdotally that it’s more Windows friendly and generally nicer to work with than git. Short review: A half baked, annoying system. I’ve spent a moderate amount of time evaluating both, and I decided to post my thoughts. However, there’s been a lot of talk lately about distributed version control systems (DVCS), of which there are two well known examples: git and Mercurial. It’s an example of a centralized version control system (CVCS), which is very easy to understand. I’ve been a long time Subversion user, and I’m very comfortable with its quirks and limitations.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |