
Mercurial 2.8 Released - japaget
http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_2.8_.282013-11-1.29
======
AlexMax
Mercurial is a fantastic VCS system that helped me get 'into" DVCS, and for
that I am thankful. Even in 2013, it feels like it has the superior windows
interface in TortoiseHG and I loved how extensions for Mercurial were usually
a lot more cross-platform than git since they were usually just written in
Python.

That said, once I got my head around the full ramifications of Git's
lightweight branching, I still think it was the better choice over named
branches and bookmarks. When learning Mercurial, SVN-minded me naturally
gravitated towards branches for everything because of the name, and learning
the distinction of when to use bookmarks and when to use branches wasn't
exactly clear until I finally understood how Git's branches worked - and at
that point the thought of enshrining branch names in the history forevermore
suddenly turned from an obvious "why not?" to a "why?". Git's interface can
always get better, but Mercurial will always have branches that live forever
in history and are named "Branches".

Still, in Bizarro-2013 where Git never existed or never got the boost from
Github, I think Mercurial would have been just as serviceable, and I think
that it's a great second option to present if you want to migrate to a DVCS
but your teammates can't get their head around Git. Kudos to them on another
release.

~~~
jordigh
There is a good reason to have branch names tattooed on commits: it makes
inspecting the history much easier. When you are looking back and history and
want to know why you did something, unless you're meticulous about encoding
this information in your commit message, it helps a lot to have it encoded in
the commit's metadata instead.

There are also hg tools that help leverage named branches, e.g. revsets. Just
today I wanted to figure out exactly on what commit did we merge the gui
branch of Octave into default. I ran the following:

hg log -r "children(parents(branch(default) and merge()) and branch(gui))"

This told me that the merge happened a year ago, and told me exactly what
commit did it. This would not be possible if the history did not record the
branch name.

I like hg's way: bookmarks for lightweight changes, named branches for long-
lived lines of development. Both have their place, and both are useful.

~~~
AlexMax
Just because Git branches are lightweight doesn't mean they MUST be
lightweight and thrown away. In your use-case, the `gui` branch ref would
point at the merge commit, so you could simply ask for it by name. Being an
old branch, however, you could then move the branch into an 'attic' or a
different namespace than the active branches so it doesn't come up every time
you `git branch`. That sort of flexibility to move branches around when needed
was what made me question Mercurial's approach to forever-branches in the
first place.

~~~
jordigh
This is but one example. On git, if there was more back and forth merging
between two branches, you can't figure out on which branch a commit was made
later by merely inspecting history unless you encode this information in
commit messages.

------
ohwp
I think it's strange that Git seems more popular. Mercurial is a great tool.
Also check TortoiseHg.

Edit: I didn't want to start a flamewar. I'm just wondering why Git seems more
popular because I think both tools are very good.

~~~
Silhouette
Mercurial is great at many things, but surprisingly, it seems quite awkward to
set up a shared repository on your network for multiple users. It doesn't come
as standard with a simple, self-contained server, and they recommend against
using a shared directory on a network drive directly, presumably because of
the wicked data loss bugs they've had (or may still have, I haven't checked
this recently).

Compare the Mercurial guidance on publishing repositories[1], which comes in
at about 15 screens on my system, with the equivalents for say Git[2] or
Bzr[3] that fit in a couple of screens, and you can see how striking the
difference is.

[1]
[http://mercurial.selenic.com/wiki/PublishingRepositories](http://mercurial.selenic.com/wiki/PublishingRepositories)
[2] [http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-
the-...](http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server)
[3]
[http://doc.bazaar.canonical.com/bzr-0.11/server.htm](http://doc.bazaar.canonical.com/bzr-0.11/server.htm)

[Edit: Rephrase to avoid sounding unintentionally trollish. I'm trying to
answer the question, not start a flame war.]

~~~
durin42
The instructions you linked for git would basically work as stated for
Mercurial, but without all the mucking about with making a bare repository.

Note that on the Mercurial wiki page you linked, it does mention ssh setup,
although perhaps not as prominently as you'd like.

Also, hg /does/ come with a simple, self-contained server: hg serve. It
doesn't support authentication, because there's a bunch of http servers that
can do that for you better and with less bugs than we'd inevitably have.

~~~
Silhouette
_The instructions you linked for git would basically work as stated for
Mercurial, but without all the mucking about with making a bare repository._

Except that if you're running Windows rather than Linux, they don't. I have
literally just tested it to make sure I'm not imagining things.

The difference is that with Git you probably also have Git Bash installed on
Windows, which while somewhat clunky does at least provide a fairly
standardised mechanism for setting up keys etc.

To my knowledge, there is no equivalent for Hg, and attempting to use hg with
an ssh:// path to the repository seems to depend on what other software you
have installed (Tortoise*, for example).

If you know better, my team and I would love to learn something. This has been
bugging us for years and across multiple projects, and none of us has ever
found a simple, effective way of doing it.

For the record, the mention of SSH setup on the page I linked to is literally
just that: a mention, with no further details at all, and as noted above the
obvious change of specifying an ssh:// path to a repository instead of a local
one doesn't work by default on Windows. There's also a second entry for
"Shared SSH", but that goes to a separate page describing half a dozen
components that mostly aren't included with hg out of the box and again seem
to lack much documentation in some cases.

[Edit: Yes, there is also hg serve, but as you point out it lacks even basic
security checks, and even the main Mercurial web site doesn't recommend
relying on hg serve for more than temporary purposes.]

[Edit 2: Rephrase to clarify shared SSH details.]

~~~
durin42
I'm afraid I know absolutely nothing about Windows. I know ssh is kind of a
basketcase there, and I think tortoise is your best bet.

Are you trying to use Windows as a server or as a client?

~~~
Silhouette
The configurations I've seen are trying to use some sort of Linux-based server
or NAS, and a variety of clients including some on Windows.

FWIW, I've just been told elsewhere in the thread that what we've been trying
using SSH should have worked out of the box as long as Hg and TortoiseHg were
both installed (and, I assume though we didn't state this, as long as Hg is
installed and properly reachable on the server side).

So, while I can confirm that the simple SSH access doesn't work reliably here
right now, it is starting to sound like we've hit some unfortunate case that
isn't necessarily Hg's fault. If so, I apologise if my comments were unfairly
harsh, though I would still suggest that Hg would be more user-friendly if it
could handle SSH connections itself without relying on additional software
that must be installed separately.

------
somnium_sn
I like that Mercurial still tries hard to get new concepts into the core.
There is something they call "phases" which is a boundary marking what was
published and what not. Phases then forbid people to rebase changsets that
were already published (unless you obv tell it to force it anyway), which is
more more convenient than git's way. In addition they work on something called
obsolete markers which will also record how changsets moved on rebase, etc
giving it much more flexibility and power than git.

------
SmileyKeith
Whenever the Git vs Mercurial topic comes up I think this thread [1] about
Facebook having massive slowdowns with their large codebase using Git is quite
interesting.

[1]: [http://thread.gmane.org/gmane.comp.version-
control.git/18977...](http://thread.gmane.org/gmane.comp.version-
control.git/189776)

~~~
the_mitsuhiko
How is this related to mercurial?

~~~
ngoldbaum
Facebook uses mercurial internally.

~~~
the_mitsuhiko
Source? That linked article is from when facebook used subversion.

~~~
ezquerra
The definitely do. They migrated their repositories to mercurial a while ago.
There are plenty of mentions of this fact on mercurial's development mailing
list (mercurial-devel@selenic.com).

Facebook is a big user and backer of mercurial. I attended the last mercurial
sprint in Facebook's London office (which was great, BTW). Facebook will also
host the next mercurial sprint in New York. They have recently hired Matt
Mackall, mercurial's creator. Several other mercurial core developers also
work for Facebook and are paid to work on improving mercurial as their main
job.

I believe at some point they considered both git and mercurial as their new
VCS. They have some huge repositories (hundreds of thousands if not millions
of commits) and a huge amount of people accessing those repositories. I think
they found some scalability issues with git's performance with repos of that
scale ([http://comments.gmane.org/gmane.comp.version-
control.git/189...](http://comments.gmane.org/gmane.comp.version-
control.git/189776)). Apparently it was easier for them to improve mercurial's
performance, perhaps because mercurial is written in python with some
performance sensitive parts written in C. Over the last year they have made a
lot of progress and mercurial's performance on huge repositories is now even
better than it used to be.

------
toggle
I'm glad that the shelve extension (which is like stash in git) is included by
default now. Even though that extension has been around for a while, it feels
like it's considered a core function now, rather than an "extra." (Especially
for git users, who are accustomed to having `git stash` out of the box. So now
there's a little less friction when trying to do the same things in
Mercurial.)

~~~
twic
Yes, it is nice to have shelve in the core.

That said, with Git, my main use of stash is to put away uncommitted changes
so i can pull updates from the origin. Stash, pull, pop. However, Mercurial is
able to pull changes into a working copy which has uncommitted changes - it
essentially just treats it as a merge. This, with Mercurial, i need to stash
much less often.

It's still useful as a way of putting changes aside while you work on
something else, though, so i am glad to have it. The alternative was doing
things with patch queues which were a bit scary.

~~~
beagle3
Is mercurial's merging significantly different than git pull --rebase? (which
acts like "cvs update" or "svn update" with respect to uncommitted changes?)

~~~
twic
Is git pull --rebase like cvs update with respect to uncommitted changes? If i
issue a git pull --rebase (with Git 1.8.2.2) in a repo in which i have
uncommitted changes, i get:

Cannot pull with rebase: You have unstaged changes. Please commit or stash
them.

From what i remember of CVS, if i update into a working copy with changes, it
applies the update where it can, and leaves merge conflict markers (or runs
your configured merge tool) where it can't. That is also what Mercurial does.

~~~
beagle3
Ok, now I understand. Yes, git expects you to commit or stash before doing
that, matching the philosophy that there _should_ be a commit you can go back
to undo (even if you have to look at the reflog to see what that commit is).

Personally, I commit and stash all the time, and feel better than the old CVS
in which I manually stashed (by copying) the pre-"cvs update" state in case I
needed to go back to it.

matsushiko above mentions that git now has --autostash; legit had "sync" which
does stash-rebase-unstash - but I rarely ever needed that workflow.

------
pnathan
I spent a few years developing tooling and processes around Mercurial, then
moved to a new role some months ago where Git is used exclusively. I am afraid
that I still prefer hg; while git is, as a rule of thumb, faster, hg takes
better care of your data (Much harder to lose changesets) and presents a
cleaner UI out of the gate.

~~~
Skinney
Much harder to loose changesets? The reflog keeps changesets for up to 90 days
(default, can be configured), if you don't notice that changesets are missing
for 90 days, then chances are they don't matter :/

~~~
twic
I am utterly flummoxed by the idea of a version control system that
autonomously discards versions _at all_ , even if it keeps them in a
mysterious trashcan for 90 days.

Last week, some colleagues of mine 'lost' some commits because some other
colleagues had misused a forced push. They could probably have got them out of
the reflog, if someone had told them about the reflog in time; before i could,
they recovered a diff from their console history. If they'd been using
Mercurial, the situation just wouldn't have arisen; they would have had a
branch with two heads, and they could have resolved that straightforwardly.

The fact that is would possible to recover from this situation using a command
that one never has any other need to even know about is no excuse for the fact
that it is even possible.

~~~
taspeotis
> some other colleagues had misused a forced push

Git has a learning curve.

Atlassian Stash comes with a plugin that exposes a "Disable Force Push"
toggle. I have that on for all the repositories it hosts. Nobody complains
that force push doesn't work (~10 devs) because if you're doing force push
you're probably doing something wrong.

~~~
twic
>> some other colleagues had misused a forced push

> Git has a learning curve.

That sounds a bit like a euphemism for "is hard to use".

However, that's not what i'm getting at. The first pair of people misused a
forced push because they're clowns. They are never going to learn to use any
version control system properly, even if the learning curve was down a slide.
If we disabled force push, they'd probably have reenabled it (they're
sysadmins, so it would be hard to stop them).

The problem is that the second pair of developers, who are not clowns, but are
also not Git power users, nor have any interest in becoming Git power users,
got screwed by the first pair's mistake, and could only have got out of it by
using an obscure feature known only to Git power users.

~~~
Skinney
> and could only have got out of it by using an obscure feature known only to
> Git power users.

Obscure? I spent one afternoon reading the Pro Git book that is available free
online. The first thing you learn, after learning to alter history, is the
reflog.

Look, everything people in our business do is based on trust. It's fairly easy
to mess up for everyone, and this includes Mercurial as well. Like switching
bookmarks around or messing with hg strip.

------
mariocesar
Right now if you try to install it using pip `pip install Mercurial` will
still install 2.7.2 version.

Do instead: `pip install
[http://mercurial.selenic.com/release/mercurial-2.8.tar.gz`](http://mercurial.selenic.com/release/mercurial-2.8.tar.gz`)

~~~
durin42
Sorry about that, I've fixed that.

------
elisee
Release notes for the companion GUI TortoiseHg 2.10 release:
[https://bitbucket.org/tortoisehg/thg/wiki/ReleaseNotes#!tort...](https://bitbucket.org/tortoisehg/thg/wiki/ReleaseNotes#!tortoisehg-210)

