Posts Tagged ‘mercurial’

Review remote changes offline in Mercurial

If you want to review remote changes from Mercurial offline you cannot use hg incoming. For sure there is a nice way to do it. So here is what I do to get changes from a repository to review them later without pulling them into my repo before reviewing. It also has the advantage that you can review changesets that include a given file. This is not possible with hg incoming.

Read the incoming changes and save them in a bundle file:

$ hg incoming --bundle incoming.bundle http://selenic.com/hg

Now you can disconnect and review them offline.

$ hg -R incoming.bundle log --no-merges -p -- hgext/bookmarks.py
(log pops up)

The -R incoming.bundle option tells Mercurial to use the bundle as an overlay for the current repository. The –no-merges option tells Mercurial to not display merges (which I usually use for reviewing patches) and the -p option is there to display the applied patches in the output. I use — hgext/bookmarks.py to display only changesets related to the bookmark extension.

Everything’s good, let’s pull it:

$ hg pull incoming.bundle
pulling from incoming.bundle
searching for changes
adding changesets
adding manifests
adding file changes
added 113 changesets with 281 changes to 204 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)

Mercurial Bookmarks Revisited – Part I

Bookmarks is an extension to the Mercurial SCM, which adds git-like branches to Mercurial. The extension is distributed together with Mercurial.
Recently the extension has received a major update. Time to look back.

This is a series of blogposts that consists of three parts:

(1) Part I: History of Bookmarks
(2) Part II: Daily Bookmarking
(3) Part III: Pushable Bookmarks

(more…)

Writing a hg to subversion gate

Using a decentralized version control system (DVCS) like Mercurial (hg) or Git as a client for Subversion is very common. With the unique features of a DVCS a developer can have both the features of offline development and local branching while still being able to push to a subversion server. This approach is often used in environments in which subversion is the given version control system. While the approach of using this bi-directional push and pull mechanism, provided by git-svn or hgsubversion, works perfectly for one developer, it has limitations working in a team using the usual DVCS push and pull concepts.

The following article will outline the current limitations of bi-directional dvcs to subversion bridges and shows a simple approach to implement a solution for a certain instance of the problem.

(more…)

hg-scm.org

For those of you, who didn’t notice so far, in the last 6 month we worked on a more userfriendly and accessible page than the current mercurial website. Three weeks ago we launched hg-scm.org which is quite similar to git-scm.org. I hope you enjoy it

Merge vs. Rebase – A deep dive into the mysteries of revision control

I remember the days when I started learning Git about two years ago. I crawled through all the available commands and read the man pages what they are for and I remember when I stumbled over rebase and stuck. After figuring out what it actually does, I start loving it, but didn’t understand it’s dangerousness until someday I somehow got duplicated commits after pulling from another repository. So let me explain what goes wrong and why merge and rebase are often misunderstood. I’ll also present a list of golden-rules about their usage. Before we start with explaining both commands, I would like to give you one of the most important rules, in case you don’t want to read the complete article.

Never rebase branches or trees that you pulled. Only rebase local branches.

(more…)

A really unfriendly and not so fair approach to GIT vs. Mercurial

Okay, this is one of the posts I wanted to since about 1 year, but now, nearly 2 years after the first git vs. Mercurial blog post I finally made it to actually write a second time about this topic. A first notice: I won’t cover bazaar. I personally hate it with passion and think it is the worst approach to DVCS ever. Nevertheless git and Mercurial fight in the same game with the same weapons (unlike bzr which is just far behind).

WARNING: This is the most subjective, most pointless approach to this topic ever. I didn’t read it myself a second time, I just published it.

I will start the same way as last time:

git
Git is a decentralized version control system written by Linus Torvalds to replace bitkeeper as the version control system of choice for the kernel because of licensing issues (okay I know this is the short story and it was much more complex and you can write a thousand lines about that, but it’s enough for most people). Git is designed to be fast. Everthing is optimized in that way. It contains a huge C written core with a lot of bash and perl scripts around it. A few years ago the C written part formed the so called plumbing. Nowadays the git community tries to replace high-level commands written in bash and perl that call the plumbing commands with c-written code to get a more consistent code base.
Let’s make a long story short:
Git is powerful. Awesome powerful. This is true since git’s beginning, but back then it lacks a good interface and the git community did a great job in improving the horrible interface git had once. Git is still awesomely fast. Commits, bisecting, everything works like a charm particularly on big projects like the kernel. They can rewrite history, they are doing a great job in helping intergrators to apply patches, reviewing them, and pushing to multiple sources. Everything about git is really unique, their focus on a powerful command set, their branching support and their targeted audience. I want to talk a little bit about that fancy branching support. Frankly, every version control system, even the 3rd generation decentralized ones have a pretty conservative way of doing branching by giving every changeset a name that the changeset belongs to (at least this is true for mercurial, and called named branches there). Git just gives a sh** about that and takes a version control branch the same way as a tree branch. It’s just an unnamed branch of the DAC. This gives you the awesome possibility to great huge set of local branches, to merge, rebase them without any bigger problem or even just discard them (actually that is one of the biggest problems in mercurials bookmarks implementation). Another just great feature in git is the staging area. You can stage hunks, as a virtual repository that is used to actually commit the ‘selected’ changesets. That’s awesome and I’m really missing that in most of the version control systems that I use. The idea of a staging area is just a huge win for git. It’s so incredible powerful. Okay to put it in a nutshell: git is just awesome, but….

There is Mercurial.
Okay some kind of a warning in advance: I contributed two well known extensions to Mercurial, I hang around in their chatroom and I think that I’m a well known part of the community. Nevertheless if you talk about Mercurial and compare it with git you have to take care. Mercurial is by far not as powerful as git, and…that is just the best think about Mercurial. Matt really keeps it simple and clear for everybody. it’s so incredible easy to understand in the first place. There are no weird commands with a thousand of flags. Okay I try to be fair. Mercurial is much less powerful than git in the first place. Because it tries to keep everything simple. There is no rebase, no cheap branching, no staging area. But there are extensions. You can learn Mercurial and know all it’s commands within 24h. They are really easy to learn, and not powerful, but they can be extended, by a large range of extensions. You can have cheap branching (bookmarks), you can have kind of a staging area (record extension), you can have patch management on top (mq) and much more. With all those extensions, Mercurial is as hard to learn as learning all git commands (which frankly is not necessary at all), but it’s more of a evolutionary approach. I know a thousand people who say that learning git is as easy. Okay, no problem. I don’t think so but it doesn’t matter, but frankly, git is missing 2 big points. Windows and an application integration: If you live in your nice Linux/BSD/foo world you are right. Git is awesome, but come on, I don’t have a freaky Windows machine, but I know that 80% of all people and more than 50% of all programmers use Windows. No they are not these bad, not geeky enough people. They are the real programmers. Those who are not freaks and take programming as a job. They don’t care (and thats good) about their environment, they just want to get things done and want to earn money. That good. And even that is not quite true for most of them, they do their stuff just faster on Windows than on Linux, therefore it’s better for them to use Windows. Okay, you might argue, but there is mysysgit and it’s even part of official git. Oh nice arguement, but frankly, junio doesn’t provide Windows binary, there is no official site to get them from, and ….. git daemon still doesn’t work perfectly nor does git-svn. It just sucks. Big -1 from me for that one.
The second pint is the worse git internal design. It’s soooo unix style. It’s cool for people that love Unix (like I do), who pipe around at least 3 commands, and know that I it starts to get funny if you pipe around 5 commands. But most of the developer want to use a nice integrated version control system. They don’t like to use fancy command line stuff with a thousand of flags, they want to do click&click (the german expression would be ‘klicky-bunti’). They want to have it integrated in their Eclipse, their NetBeans, Visual Studio, their Windows explorer and so on, and frankly, git does a poor job in that area. I know there is an eclipse plugin (but the mercurial one is stilll a thousand times better), and all this fancy stuff, but what do they do, damn, they have to parse the shell output. This means either git will never ever change their shell output (which would be sad, e.g. I hate the # in git status), or they will break older stuff. Mercurail on the other side is really easy to interface with. Okay you need python but that’s all. Everything else is just smooth. It’s easy to handle, it’s easy to integrate, it just works fine. Git really does a bad job on that. And the git community knows it. That’s why they start their libgit, and libgit2 project, because they know something like a git library is needed.

Okay it’s late and I want to finish that without reading it a second time, no frankly, this time I want to be completely unfair, without any objective argument: So here comes my final words, make them:

If you like to play with software, if you really like to have the power, go for git, if you use Linux, even better, go for it, there is nothing equal to the power and the fun you can have with Git. You can be a thousand times more productive. But if you, or people in your team are not tech-geeks. If you use Guis and want to use Windows, believe me, you better use Mercurial. I really love both systems (as long as you don’t use bzr even SVN is fine), but in this use case Mercurial is just better. Think about it.

shame on myself: song for this post: This is the life by Amy MacDonald

Mercurial bookmarks

Please note that this blog post is outdated. please refer to the mercurial help for more information about bookmarks.

A few month ago, Matt Mackall the maintainer of the Mercurial version control system, came up with the idea to implement so called bookmarks for mercurial.
(more…)

bitbucket.org

I recently discovered bitbucket.org which is a polished hosting platform for mercurial. It is pretty much like github.com but much smaller. I really like the idea and the implementation of having a cooperative platform which allows you to watch and fork projects. So that’s why I moved my hgbookmarks implementation from freehg.org over to bitbucket.org with a free account.

But the best thing is that it is still very familiar with the main developer jesper hanging around in the #mercurial channel on freenode. He actually changed a few things on my repository as I’m too lazy to setup them up in the first time. Thanks for that.

Hopefully it will grow like github. Well at least I’m thinking about getting a $5/month account on it.

hgbookmarks is a implementation if git-styled branches for mercurial. It allows to create local bookmarks on certain commits that move forward with any commit. You can merge and update those bookmarks. You can think of bookmarks as named commit sha1s

mercurial’s pager

For quiet some while, I play around with distributed version control systems. Particularly GIT. To think outside of the box I, sometimes try out mercurial. Mercurial works like a charm, only the lack of using a pager to display logs or other long output annoyed me. For sure I could define an alias or always pipe the output to a pager, but I looked for a “out-of-the-box” solution, like GIT provides one.

To make a long story short, the latest changesets on mercurial added a pager extension. To enable the pager, just add the following lines to your local .hg/hgrc or to your global .hgrc:

[extensions]
hgext.pager =

By default, the pager extension uses the environment variable $PAGER.

As mercurial want to be more platform independent than GIT, the developers care about not doing too much platform-dependend stuff. Therefore, if you use less(1) as a default pager, the pager will popup always, even for a oneliner. GIT avoids this by defining special less environment variables, which are to specific to be included into mercurial. To fix that behaviour yourself either define the environment variable LESS=’FSRX’ in your .bashrc or override the pager used by mercurial using the folliwng line in your .hgrc:

[pager]
application = LESS=’FSRX’ less

The pager extensions tries to do exactly the same as if the output would be piped on the bash. Therefore you might notice BROKEN PIPE errors, when you quit the pager before mercurial finished to write all the output. If you get annoyed by that error, use the quiet variable to silence it. It is not enabled by default.

[pager]
quiet = True

Browsing long changesets is now joy.

Git vs. Mercurial

After using CVS and SVN for years now, I finally stumbled over distributed version control systems (DVCS). Beside the commercial BitKeeper there are various Open Source projects around. The most famous is probably GIT which was initially developed by Linus Torvalds and is now maintained by Junio C. Hamano. An other approach is Mercurial which started in the same time when GIT started. There are several other (bazaar, monoton), but I’ll focus on these. The systems have some concepts in common but differ at some point. I don’t want to give you a deep introduction to the DVCS approach, there are enough tutorials around that cover this topic well.
(more…)