
What's New in Mercurial 3.0 - anton_gogolev
http://hglabhq.com/blog/2014/4/29/what-s-new-in-mercurial-3-0
======
tomlu
I feel like Mercurial still has a chance to become a real force if it can
provably solve some of the _real_ issues with git. It won't do to just have a
nicer CLI since most people are used to git by now.

Here are some of git's real problems:

* Performance issues with multi-GB git repos * Handling of large binary files * Submodules - Mercurial has subrepos, but I don't know how they compare

~~~
colechristensen
There is opportunity for a powerful tool to handle the very common bad
practice of including giant binary blobs which don't belong in version
control.

I'd like to see a second class of files which are only checksummed (or
timestamped) on 'status', 'diff', 'add' and then binary-diffed on commit for
possible compression (or perhaps deduped with checksums of blocks) with
features like 'git/hg binary-add somefile.jar' to differentiate.

~~~
tomlu
> There is opportunity for a powerful tool to handle the very common bad
> practice of including giant binary blobs which don't belong in version
> control

Why do you say it's bad practice? Game assets come to mind, these aren't
derived artifacts and you can't build the game without them.

~~~
wtallis
Usually, you can build the game without them, up to the final packaging stage.
Almost any game that is built on an engine can have all of the asset files
swapped out without having to recompile anything, and as long as the file
format and structure for assets is relatively stable there doesn't have to be
a tight coupling between engine versions and asset versions except when doing
QA and benchmarking.

This is one of the cases where git's inability to handle rewriting a public
history is a pain. The art and programming departments should be able to
develop along separate branches, and the programmers should be able to pull a
tree from art that has everything between tags squashed (but in a reversible
fashion in case there's a need to bisect something later).

~~~
tomlu
There usually are dependencies between the game and its assets, but sure,
these dependencies can be managed.

Historically I've dealt with the problem by keeping code and assets in
separate repositories (using different version control systems). While it's
worthwhile to do so in order to use git for code it really is a pain.

~~~
colechristensen
Exactly my initial point. It is really worthwhile to treat code and binary
data differently, and the tools don't exist to make it not-so-painful.

To answer a couple of levels up, it's not bad practice because it isn't
useful... there are many circumstances where having big binary blobs versioned
and associated with code. It is bad practice because the tools are all written
_for_ code and can get nasty when filled with binaries.

So there's a problem and a solution, but nobody seems to have put together the
right magic yet.

------
wirrbel
While a lot of tutorials mention how complicated git is in contrast to
mercurial I - being a git native - feel the other way around. Git is intuitive
with a small number of concepts necessarry to grasp my whole workflow.

Using this workflow with mercurial is really frustrating when I do it - the
occasional pull request for a python-based project. A git branch as a concept
is really simple, the mercurial ways I just cant wrap my head around (granted
I only use it occasionally).

As a platform I like how all the porcellain in mercurial is implemented in a
high level python. I can only wonder how productive writing custom porcellain
commands in mercurial is given that interface.

~~~
gecko
There are two things people mean when they say Git is complicated.

Some people mean that Git's _model_ is complicated, which what you're talking
about. I actually find its model very simple, some people find it complicated,
but at any rate, I certainly think Git and Mercurial have comparable
complexity in the model.

What most people mean, though, is that Git's _UI_ is complicated. To be blunt,
I think this is simply objectively correct. For example, "git checkout foo"
might mean go to the foo branch, or might mean revert a file called "foo".
There is no way to know. If you want to be sure to revert a file called foo,
you can do "git checkout -- foo", I believe, but I don't know a branch
equivalent (and it at any rate won't be symmetrical). Want to create a new
branch? That's "git checkout -b newbranch". Want to delete it? That's "git
branch -d newbranch". There are _tons_ of things like this in the Git UI,
where commands have basically arbitrary parameters in different contexts.

Way back when Git was first created, the plan was for what is now called Git
to be the underlying _implementation_ of a higher-level UI. I really,
profoundly wish that had actually panned out. Instead, Git's low-level
commands gradually grew more user-friendly until it hit the "good enough"
zone. _That 's_ what people usually mean when they say Git's complicated.

~~~
__david__
I feel that people that rail on "git checkout" don't actually understand what
it does. It does two things: 1) unpacks files from the repository into the
working directory, and 2) updates the current working branch.

Want to revert your changes? That's unpacking from the repo to the working
dir. Want to switch to a different branch? That's _also_ unpacking files from
the repo to the working dir. The only difference is that in one case the
current working branch stays the same and in one case it changes (or you could
look at it as in one case you set it to the current value and in the other you
set it to something different).

This is why people say you need to understand the underlying model of git to
grok it. The commands make perfect sense from the perspective of the data
model.

Also, want to create a branch? "git branch new-branch". Delete it "git branch
-d new-branch". The "checkout -b" is an optimization, just like "rm -r x" is
an optimization of "find x | xargs rm" (why do two commands when you can do
one?).

The only thing I don't like about git UI is that it can't decide what to call
the "index". It's called "index", "staging area", and "cache" in various
places (including command line flags), which is confusing.

~~~
jordigh
> This is why people say you need to understand the underlying model of git to
> grok it. The commands make perfect sense from the perspective of the data
> model.

Making people understand the internal data structures in order to understand a
UI is... not good.

~~~
edavis
See, but I don't think they're "internal" at all.

The "underlying model of git" that David refers to (blobs, trees, commits,
tags, branches, HEAD, etc.) aren't seen as internal data structures to be
glossed over by a UI. They're the very essence of git.

~~~
rkwz
> The "underlying model of git" that David refers to (blobs, trees, commits,
> tags, branches, HEAD, etc.) aren't seen as internal data structures to be
> glossed over by a UI. They're the very essence of git.

Users don't need to know the 'very essence' of a tool inorder to use it. Do
you think that people who drive cars know in detail about how car works? They
just need to know about starting a car, making it go forward, backward,
parking etc and that's what most car drivers care about.

~~~
__david__
You don't have to understand how a carburetor works to drive a car, but you
_do_ have to know that "Drive" connects the engine to the wheels.

Git is like driving a manual transmission. In a manual car you have to
understand that the clutch disengages the motor from the drive shaft and how
the different gears work in general. It's not rocket science and most people
can pick it up.

~~~
masklinn
> Git is like driving a manual transmission.

Git is nothing like driving manual.

> In a manual car you have to understand that the clutch disengages the motor
> from the drive shaft and how the different gears work in general.

No, you most definitely don't, that's complete lunacy. The vast majority of
(manual) drivers[0] have no idea how things work and they don't give a fuck.
Different gears are for "go faster" and "go slower", and the clutch is for
"change gear". People learn to do it right because the alternative is to stall
or get a horrible grinding sound and pay top bucks to get stuff fixed, not
because they understand how things work under the hood.

[0] in countries where it's the norm, not in countries like the US where
manual is for nerds and passioned

~~~
__david__
> Different gears are for "go faster" and "go slower", and the clutch is for
> "change gear".

Sorry, that's exactly what I meant by "the different gears work in general".
You need to understand that underlying model before you can make it work, even
if it's only intuitive, and not cerebral.

> the clutch is for "change gear"

That, and it's also "don't stall when I stop".

I think most people understand that it disconnects the engine. I don't think
that's as crazy a leap as "understanding the details of how a gearbox works"
(which I don't even know, since I've never looked in one).

Anyway, I maintain that my analogy is apt.

~~~
masklinn
> You need to understand that underlying model before you can make it work

No, you only need to understand what the final effect is. The vast majority of
drivers neither understand nor care that gearbox speeds change the conversion
ratio between the engine's rotating speed and the axle's, if you did and had
to gear speeds would be labelled by their conversion ratio not 1-6 (and then
you'd have to include the axle's conversion ratio in the mix). And I don't
doubt that a Git-based gearbox would do exactly that, and that going in
reverse would require either using an inverter or would require using a
completely separate reverse transmission.

> Anyway, I maintain that my analogy is apt.

And I maintain that it is not.

------
VoiceOfWisdom
I am so excited for Changset Evolution. The only thing I miss having from git
in mercurial, is the ability to safely rewrite commit history.

~~~
krallja
I'm excited because it is SO MUCH more powerful than git's commit history
rewriting, because "I re-wrote history" becomes part of your (distributed)
repository's history.

~~~
bru
Could you explain this difference to a git user?

~~~
gizmogwai
In git, when you rewrite your history, the old version is gone (well, you
still have the revlog for 30 days, but then it's basically over). This is why
some commands like `git push --force`after a rebase can cause so much hassle
to a community (hello Jenkins!) Here, the principle is te keep all the
history, and its rewrites, forever, and to ease the distribution of those
changesets.

~~~
Crito
Nitpick: The old version will not be gone unless it is no longer reachable
from _any_ of the refs. Making it no longer reachable from merely one of many
refs will not cause it to be GC'd.

This isn't really a nitpick though, since this means that similar porcelain
could be implemented on top of git fairly easily. The underlying data-model
supports it.

------
EGreg
Changeset evolution puts mercurial slightly ahead of git here

Now if only Atlassian's bitbucket was as popular as github!

~~~
Fice
For me, the extreme popularity of GitHub is the No. 1 reason to avoid it as I
do not want to contribute to the centralization of the Web. Also I like
Fossil's [fossil-scm.org] approach of integrating wiki and bug tracker into
DVCS, which allows projects to be less dependent on hosting services.

~~~
wirrbel
Fossil's user base has yet to reach a critical mass, mercurial and git are at
least widely used and plugins, and services exist. I wonder if darcs will
become a viable option again.

For git there is ticgit, which is a tracker that lives as a git branch.

Its definitely great to have several tools available and see a really
productive evolution for good version control systems.

------
brianolson
See also :
[http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_3.0-rc_...](http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_3.0-rc_.282014-04-17.29)

------
frik
Has Facebook switched to Mercurial? In one news it says so, in the next one
read it has a ~50GB Git repo. If they really switched, it would be a good
advertisement for Mercurial and its capabilities.

~~~
alwillis
Seems like they’re in the process of switching; they have lots of code to
migrate: [https://code.facebook.com/posts/218678814984400/scaling-
merc...](https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-
facebook/)

------
philtar
Can someone explain why the push in the example (that people familiar with hg
would recognize) failed?

~~~
anton_gogolev
There are a couple of settings in repository-level configuration file which
tell Mercurial where to pull from (`default`) and where to push to (`default-
push` or `default`; think "remotes" in Git parlance):

    
    
        [paths]
        default = http://live.hglabhq.com/hg/hgsharp/hgsharp
        default-push = http://live.hglabhq.com/hg/hgsharp/hgsharp
    

When you create a new repository with `hg init`, the `[paths]` section is,
naturally, empty, hence the complaining.

------
ksec
Has any of those Facebook Performance patch been merged with 3.0 yet?

~~~
mrtngslr
Yes, they are merged. The Facebook guys have been doing a great job optimizing
things all over the place (revsets in particular).

