15 ms·

Adding Mercurial support to Gitlab

277 points by testcross 8y ago

maxxxxx 8y ago
I still don't understand why git became so popular in comparison to Mercurial. Mercurial seems like a much more friendly and sane system. I hope adding it to Gitlab will help its popularity.
- LukeShu 8y ago
  Having a local "bare" copy (to use Git's term; `hg clone -U`) of the Mozilla repo, I'd like to create a checkout of it (`hg clone`), and build Firefox from it. This results in 90 minutes of waiting with hg pegging one CPU core (CPU-bound, not disk-bound!), then a few minutes of hg actually writing files, then the actual build taking 60 minutes. In the git community, it was always taken as a sign that they were doing something right that `git clone` was faster than `cp -r`. I'm having a hard time not taking it as a sign that Mercurial is doing something wrong that `hg clone` is so much slower. edit: The saying was that `git checkout` is faster than `cp -r`, not that `git clone` is. The sentiment stands.
  - voltagex_ 8y ago
    How is git clone faster than `cp -r`?
    - dleslie 8y ago
      It may be in relation to when you duplicate a repository. When you cp an active git repository you receive an identical file state; when you git clone you receive only what is necessary. Old objects, reflogs, et al aren't in the clone. A clone of an existing local repository may also make hard links, if your file system supports it.
    - simcop2387 8y ago
      My first guess would be that git is going to be faster since it won't be doing a huge number of stat() calls and similar to grab metadata about the files it's creating, instead git will have the data in a single data structure it can efficiently ask for it from. Of course the filesystem has this too, but git will have it in a single location and probably more compactly, leaving it able to do it all with fewer reads. Then it has the data in the files compressed so the read is faster too. All this should mean that git can get to writing the files faster than cp will.
    - LukeShu 8y ago
      http://gitolite.com/git-performance.html http://gitolite.com/git-performance.html (the obvious answer) https://apenwarr.ca/log/20080121 https://apenwarr.ca/log/20080121 (some more nuance)
  - sometimesijust 8y ago
    I have pulled and built Firefox from scratch over Australian internet in less than half that time? In general I have found all Mozilla repos to be an order of magnitude faster for this type of operation than the equivalent Google/Chrome repos (not using build caches).
    - LukeShu 8y ago
      The actual network clone is faster than that. The slow clone that I'm speaking of is cloning from one place on my hard drive to another place on the same hard drive.
  - ygra 8y ago
    Mercurial tries to use hardlinks to share as much actual repository data as possible when doing a local clone. Maybe that's the part that's interfering here. You can try using hg clone --pull instead of just hg clone, which will not do hardlinks. Don't have much experience with terribly large repositories in Mercurial, though. Those we have at work have maybe a few thousand files and less than 20k commits and they're not particularly taxing.
    - lwf 8y ago
      `git clone` will also use hardlinks by default. --local, -l When the repository to clone from is on a local machine, this flag bypasses the normal "Git aware" transport mechanism and clones the repository by making a copy of HEAD and everything under objects and refs directories. The files under .git/objects/ directory are hardlinked to save space when possible. If the repository is specified as a local path (e.g., /path/to/repo), this is the default, and --local is essentially a no-op. If the repository is specified as a URL, then this flag is ignored (and we never use the local optimizations). Specifying --no-local will override the default when /path/to/repo is given, using the regular Git transport instead.
  - durin42 8y ago
    How long ago was this? And what OS? I know we're faster than unzip on some platforms, but IIRC we just found a pretty awful performance issue on...linux? I think?... that meant our parallelized approach to writing files was burning a ton of time in the kernel filesystem locks or something.
    - LukeShu 8y ago
      Just a few days ago. Parabola GNU/Linux-libre (like Arch Linux). On btrfs, if that makes a difference. From what I could tell, whatever the slow part is, it wasn't parallelized at all; of 16 cores, 15 were idle, and 1 was pegged at 100% (and very low disk-wait). I've been meaning to dig in to this more. I'd tried adding --stream, figuring that maybe it was re-compressing the entire repo; but that just lead to a warning about "server doesn't support streams" or something like that. I'll definitely try ygra's suggestion to try --pull, and if that doesn't yield good results, I'll actually dig in to the sources and see what's going on.
      - durin42 8y ago
        Sounds a lot like https://twitter.com/indygreg/status/1028097388261433344 https://twitter.com/indygreg/status/1028097388261433344 - I'm pretty sure Greg was working with hg when he noticed this issue. In any event, if you're enthusiastic about this kind of thing, we'd love to have more eyes on making hg checkouts consistently fast, even in the face of filesystems undermining those efforts. ;)
        LukeShu 8y ago
        If it were just btrfs being silly, I'd expect the high CPU usage to be attributed to a kernel thread, not to the hg process. But we'll see :)
- xtreak29 8y ago
  I use hg at work and git for open source. I can agree that GitHub and GitLab add momentum to git. Bitbucket is the almost the only provider. I feel hg can do the same things like git but a lot of that power is hidden under extensions in hg. I also love git releases that add a lot of UX improvements. Git is also fast compared to hg due to python startup time and it's one of the reasons hg still remains on python2. There is some effort on reorganizing python startup layout which will lay the foundation for faster hg. I hope with GitLab support hg gets more support and visibility.
- pjmlp 8y ago
  Simple, Linux.
  - another-cuppa 8y ago
    This is definitely part of the reason. Back when git was first released there was a huge amount of scepticism about whether anyone actually needed it, but lots of people used it anyway just because they wanted to use what Linus made for Linux. I think since then many people have realised that Linus was right and that git is good, but it just wouldn't have gained so much momentum without Linux.
    - akvadrako 8y ago
      I don't think people found git better than hg (or monotone), but it got a lot more attention (due to Linus) and using two different systems is a pain.
- JoshTriplett 8y ago
  Speaking as someone who used both Git and Mercurial, and who has used both to contribute to projects: Git's concept of branches as simple names for commits, and the ability to switch branches really easily within one checkout (rather than encouraging the use of multiple working directories) helped hugely. Mercurial grew the ability to do git-style branching later, but git had it from the beginning. Git has always treated performance as a first-class feature, and that has enabled certain types of workflows that Mercurial makes painful. Git is fast enough that many things don't feel like they take any time at all. Git integrated first-class support for carefully constructing and reworking a set of patches to be sent by email. Mercurial again eventually grew such support, but early on, it was much more insistent that all branches must be kept around, and by the way are you sure you don't want to push your development branch experiments up to the server and keep them there forever since you haven't merged that head into the mainline? Even later on, mercurial had more of the functionality people wanted but relegated it to "extensions", while Git shipped it out of the box. Take a look at https://walac.github.io/mercurial-for-git-lovers/ https://walac.github.io/mercurial-for-git-lovers/ (from 2015) for just one of many examples.
  - hyperpallium 8y ago
    What is hg's underlying data model?
    - JoshTriplett 8y ago
      I'm not an expert in mercurial, and I'll defer to those who are. My understanding is that while Git stores a tree of objects indexed by hash (and then packs them into packs along with an index, which can be repacked arbitrarily later on), Mercurial's primary data format is a log-structured list of revisions as deltas.
    - Zash 8y ago
      Abstractly, it's exactly the same as git. Commit → File tree → File data blob. The underlying data structures used are different, but considered an internal detail, so could be changed in the future. Today, most data is stored in a "revlog", where data can be either be stored (compressed) directly or stored as a (compressed) delta against an earlier version. Deltas may be chained. The index consists of fixed size records, which gives fast lookups, which are also linked to global revision numbers so that you can eg quickly find the commit based on a specific file change. Obs: This is based on attempting to re-implement the basics of Mercurial from scratch.
- paulwithap 8y ago
  I think git became dominant because there's no MercurialHub
  - JimDabell 8y ago
    Bitbucket was the Mercurial equivalent of GitHub.
    - ksec 8y ago
      I think Github was way better than Bitbucket in its early days.
  - weberc2 8y ago
    This is the correct answer. For some reason, the top-voted comment is some nonsense about Git's branching, which was never something I've desired or every found useful in a decade of rigorous daily use with both. To the contrary, git's branching model still trips me up all the time, specifically when I want to do things like list all the commits in the branch. Basically the problem is that unlike Mercurial branches which are actually branches while git branches are just a pointer to a particular commit. That pointer has no knowledge about what other commits are in the branch and the pointer can be moved anywhere across the tree (even to unrelated commits) with ease. Apart from the reflog, it's basically not possible to ask about the set of commits in the branch. The best you can do is never ever move the branch pointer except forward and make a note of the branch that your branch branched off of so you can do things like `git diff my-branch..parent-branch` (`hg diff -b my-branch` iirc). And this is just one of dozens of git warts.
- rimliu 8y ago
  As someone who did a presentation on DVCS for the local PHP devs in 2008 I have no problem understanding that. I covered Git, Mercurial and Bazaar. Even back then I predicted that git will win. It might not look very user friendly, but the foundations were rock solid. Branches on Mercurial seemed very clunky compared to git's.
- mprev 8y ago
  The battle seemed to be between Bazaar and Mercurial for so long. Both were easy-ish to use and both were written in Python. Mercurial usually had the speed advantage but then git came along and wasn’t written in Python. Speed wise it blew Bazaar and Mercurial out of the water. It was harder to learn for someone used to svn, perhaps, but the sheer weight of both Linus and Linux made it hard to ignore. I think GitHub deserve a lot of the credit for git’s omnipresence, though. With Launchpad our aim was to create something bigger than “just” a code sharing site and fairly or unfairly both Launchpad and Bazaar were seen as too close to Canonical. Whereas GitHub picked up the mantle that Sourceforge had dropped and made something way more collaborative than Sourceforge but held onto the idea of being a neutral third party.
  - inferiorhuman 8y ago
    Bazaar... now there's a name I've tried to forget.
    - stevekemp 8y ago
      I think my history went something like this: RCS -> CVS, CVS -> SVN, SVN -> Darcs, Darcs -> Mercurial, then Mercurial -> Git. Bazaar I had to use for interactions with Ubuntu, but never in a serious way. Similarly I used a few other things such as Visual Source Safe (shudder), SCCS, and even BitKeeper, but I think they were used quite shallowly.
  - lake99 8y ago
    > Speed wise it blew Bazaar and Mercurial out of the water. Benchmarks for this are hard to come by, and are for versions that are considered quite outdated now. But from what little there is, there wasn't that much of a performance difference between git and hg. For example, see this: https://www.draketo.de/proj/hg-vs-git-server/test-results.html https://www.draketo.de/proj/hg-vs-git-server/test-results.ht...
    - mprev 8y ago
      Well, sure they’re outdated because we’re talking about stuff that happened at least ten years ago. As for benchmarks, I don’t have any but there’s plenty of anecdata elsewhere in this thread that echoes the idea that git had significant speed advantages over both bzr and hg.
- vnorilo 8y ago
  While I don't consider myself a wiz, I'm fairly proficient at both (was responsible for stuff like lfs and submodule reorganization on git in my previous job). I'm honestly surprised that someone adept at one would struggle with the other: you basically just need to understand the semantical differences in branching. On windows, hg plays much nicer with powershell (ok, so clean is an extension, otoh hg -nu | rm).
  - philjohn 8y ago
    It's not even that - it's mostly just the commandline interface needing you to learn several arcane commands to do simple operations. Of course, if you understand the underlying data model, they seem far less arcane, but that's the problem with Git that Mercurial doesn't have - you really need to understand what's happening under the hood to get proficient at it, whereas Mercurial has a far saner interface that hides the internals under a better abstraction.
    - jazzyjackson 8y ago
      I agree with this, but OTOH, in my experience git actually has a nice smooth learning curve for a little while until you hit your first 'wtf did did I just do' snag. I just know on my team or 5 much less technical people, the concept of version control and how to do operations in Mercury was near impossible and it fell on one person to manage merging files with master. Also, this was a distance learning course where the head institution (MIT Media Lab) was keeping a central repo of every location's additions, and the changes made the repo so big that we had hard caps on how much data we could upload. Later on, it fell on me to introduce git to some colleagues. Just walking them through 'checkout','branch','merge','push','pull' got them on their feet and contributing to a repo. If they hit a wall, I could help detangle the knot, but at least we were in it together.
    - jgraham 8y ago
      I really don't think that mercurial is very good at hiding the internals. Consider a common operation; asking for the commit history. If you type `hg log` you get something very close to a prettified view of the internal datastructure by default; a list of all commits in the repository, in the order they were added, each annotated with a sequence id that's an index into the internal list. So a new user has to learn: * hg log by default doesn't tell them anything about the current code they're working on; it's just a dump of everything. To get the history of the current working copy they need to pass -f which they are learning in other contexts means "do something unsafe". * hg gives commits sequence ids that can locally be used in place of the commit sha, but must never be shared across repositories. In practice at Mozilla I have seen people run into both these issues, causing much unnecessary confusion.
- bipson 8y ago
  We used hg in a uni project once, since large parts of our team had never used a VCS, and on of our advisors urged us to consider hg. (This was around 2010, so I guess hg improved considerably since then.) Even considering the additional overhead, we switched to git after a few weeks since the repository was constantly broken, and the two of us that knew git and SVN were desperately searching for the consistency and tools we had in git. At least we could support the team from there on and make it work for them. Not the ideal solution, but the best available to us. So I totally understand why git is more popular than hg. Until hg could be considered mature enough for larger teams, git already had a huge following, IMO.
  - lclarkmichalek 8y ago
    Given that all of Facebook's repository's are hg based, I think it's fair to say that is pretty mature for large team use cases
    - bipson 8y ago
      Facebook didn't use hg until 2012 or later. I was talking and only know about the state of hg in 2010/2011 and at that point, git was widespread, stable and widely more useful than hg for anything besides simpler/smaller projects, again IMO.
      - andrewshadura 8y ago
        Hg was pretty mature by 2007 when I started using it.
  - mixmastamyk 8y ago
    I used hg for years before finally succumbing to git. Never had a single issue with hg.
- MikusR 8y ago
  In Windows Git allows to use non ascii letters for filenames.
- simias 8y ago
  I used Mercurial as my main DCVS (and even pushed it at work) for many years, but now I faced the fact that git won and use it for everything. I have to use git anyway, so I might as well not deal with two different workflows and use git exclusively. Mercurial was ahead of git for a long time as far as usability and documentations were concerned. I still think it's a better match than git for many uses cases. Mercurial makes the simple stuff simple and the complicated stuff complicated (although still achievable), whereas git is more of a mixed bag in my experience. Git was superior for very large projects with many contributors working on completely different features and sending each other patches by email (e.g. the Linux kernel) but in practice 99% of projects, both FLOSS and corporate, don't have this profile. Git is a formula one, mercurial is more like a comfortable Sedan, so to speak[1]. I think git made it mainly because it could boast hosting the Linux kernel development and all the cool kids were on github. [1] Which reminds me of this "Git is MacGuyver, Mercurial is James Bond" comparison which is probably widely out of date by now: https://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ https://importantshock.wordpress.com/2008/08/07/git-vs-mercu...
- dekhn 8y ago
  From chatting with various folks, I think git had some features before Mercurial did. I recently adopted hg and found it much smoother to use, but learned also that many of the features I depended on were added only very recently.
- IshKebab 8y ago
  I would say a combination of things: 1. Network effects of github becoming popular. 2. It's faster. 3. Linux uses it and it was written by Linus (must be good in some people's minds).
- camgunz 8y ago
  Ruby and Rails were big at the time, and those communities really took to Git. There was kind of a competition between them and Python, so maybe that had some influence on not picking Mercurial/Bazaar, but regardless I think it wasn't as grounded in technical points as we'd like to think.
marcinkuzminski 8y ago
For a self-hosted option please check out RhodeCode has the first-class support of Mercurial, including largefiles, evolve, phases etc.
- alwillis 8y ago
  Kallithea is fork of RhodeCode, fully supports Mercurial and Git and is open source: https://kallithea-scm.org https://kallithea-scm.org.
  - marcinkuzminski 8y ago
    RhodeCode is open-source too and unfortunately looks like Kallithea is a dead project by now. It didn't have a feature release since 2015, only a few bugfixes.
Annatar 8y ago
Mercurial is much easier to understand and use than git, and for the most part has feature parity with it. The only drawback was the decision to implement it in Python, which makes it very slow for large codebases with gigabytes in binary files. However, I'm given to understand that core performance parts are being re-implemented in C.
- stevekemp 8y ago
  Several parts of mercurial are implemented in C. There is an ongoing plan to recode some of the core in Rust: https://www.mercurial-scm.org/wiki/OxidationPlan https://www.mercurial-scm.org/wiki/OxidationPlan
  - Annatar 8y ago
    Recoding it in Rust would make Mercurial instantaneously unportable to any operating system which does not have a Rust compiler.
    - dmytrish 8y ago
      Hopefully, it would increase pressure to actually port it there or to use another compiler like mrustc[0] [0] https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
    - Bjartr 8y ago
      What kind of platforms would you be worried about missing out on. Rust platform support[1] looks pretty solid, but of course isn't that of, say, C, but in practice I am not aware of (but would love to learn about!) Use cases for running a vcs on more obscure platforms. [1] https://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html
      - Annatar 8y ago
        "I don't recognize your platform. Rust runs on Windows, Linux, Mac OS X, FreeBSD and NetBSD. If you are on one of these platforms and are seeing this then please report an issue, along with the following values: navigator.platform: SunOS i86pc navigator.appVersion: 5.0 (X11) To install Rust, if you are running Unix, run the following in your terminal, then follow the onscreen instructions. curl https://sh.rustup.rs -sSf | sh" ...and running that gives: curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure And I am running UNIX, a true, AT&T System V, Release 4.0 UNIX: Solaris 10 on i86pc. I don't want to have to give up Mercurial just because someone somewhere is trying to be trendy by rewriting parts of it in Rust, because he thinks that's all the rage now.
Walkman 8y ago
It's GitLab, not MercurialLab. Hope they realize this and refuse to merge. I really like shared tooling and knowledge, so if Git dominates everywhere, all you have to do is learn git and that's it. It's a significant overhead to learn yet another VCS just because it is a little nicer. I hate wasted efforts.
- deleted 8y ago
  [deleted]
- hvidgaard 8y ago
  Do you really want a dev environment where there is only one way of doing things?
  - Walkman 8y ago
    Yes! Absolutely! So I can focus on innovating where it matters (the product I'm developing). It alao would mean those things would be extremely polished (because a lot of people affected and interested to make it good). Also I would not need to learn so much random stuff I don't really care about.
    - hvidgaard 8y ago
      You're free to choose a tool and use that so you can focus on the product. But only having one tool would be rather counter productive for the community as a whole.
    - rleigh 8y ago
      This level of rigidity would preclude the gradual adoption of newer workflows, and hence be a hard blocker preventing any improvement or advancement. I hesitate to criticise it, but I don't think such an environment would be polished. A frozen environment is one which can't be improved, so will naturally stagnate. You couldn't achieve a state of being "extremely polished" because those who cared to do the polishing would be denied the ability to do so because it requires change in order to do so.
krob 8y ago
Oh the irony, phabricator has had mercurial support since day one almost.
- kjeetgill 8y ago
  I'm unfamiliar with phabricator's history. What makes it ironic? Did it have both out the gate and meet criticism?
- mappu 8y ago
  I evaluated phabricator today for Hg hosting at $DAYJOB. Issues in Maniphest aren't "attached" to a Diffusion repo, so you can't use it as a Gitea/Github-style one-repo-one-project system; it's one-phabricator-one-project-multi-repos. Spaces help a little bit but not really. Dealbreaker for us - we'd rather retrain staff on hg->git (and lose the amazing TortoiseHg).
- arunc 8y ago
  Phabricator doesn't support fork model.
kjeetgill 8y ago
Hm. My understanding is that the git and mercurial worlds follow different workflows around branching, merging, forking, etc. Does that cause a huge impedence mismatch in the UI? Or will they converge? In the same vein, I wounder if it's possible for a single repo/history to be checked out with either tool. You clone with hg, I'll use git. We both merge with patches as a common language. Disclaimer: only use git
- y4mi 8y ago
  bitbucket supports both as well
erlend_sh 8y ago
For a strong contender to "next-gen DVCS", I recommend checking out https://pijul.org/ https://pijul.org/. Written in Rust and based on a sound theory of patches. If GitLab actually merges Mercurial, I sincerely hope Pijul is next.
- mattbee 8y ago
  That sounds identical to darcs' pitch - http://darcs.net/DifferencesFromGit http://darcs.net/DifferencesFromGit darcs was an absolute pleasure to use, right up until they got stuck on the "merge of doom" bug http://darcs.net/FAQ/Performance#is-the-exponential-merge-problem-fixed-yet http://darcs.net/FAQ/Performance#is-the-exponential-merge-pr...
  - autopoiesis 8y ago
    I think pijul's algorithms avoid the "exponential merge problem", though I don't know the details: https://pijul.org/manual/why_pijul.html#better-conflicts-for-everyone https://pijul.org/manual/why_pijul.html#better-conflicts-for...
  - WorldMaker 8y ago
    Pijul is definitely inspired by darcs and from what I've seen most of its team is very familiar with darcs.
- sleavey 8y ago
  On a shallow note, I hope the command is changed or aliased if this becomes mainstream - writing "pijul" at the start of every command is awkward on English keyboards given that all the letters are near to each other on one side. Writing "git" or "svn" on the other hand, the letters are spread across the keyboard and shared between hands.
  - Already__Taken 8y ago
    You don't alias git to just g?
asdadasdadasdas 8y ago
Sounds interesting. Is GitLab still just a bunch of guys somewhere in Ukraine? What is the likelihood of "it was an amazing journey" scenario?
testcross 8y ago
I read a few articles about a new way to work with hg that appeared in the past few years. They were saying that we don't need to have names on every branch. That actually we don't need to name many things and it works much more smoothly. I wonder what is the opinion of hg users here.
MordodeMaru 8y ago
Who other than FB albeit customized is using Mercurial in prod?
- mi_lk 8y ago
  JaneStreet I believe.
- alwillis 8y ago
  Mozilla.
  - MordodeMaru 8y ago
    Really?
    - alwillis 8y ago
      Yes: https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/index.html https://mozilla-version-control-tools.readthedocs.io/en/late...
- alwillis 8y ago
  Nginx: hg.nginx.org/nginx.org
julia_lang 8y ago
Off-topic, but I think GitLab has incredible good (fast) marketing. If there's any inconvenience their CEO and his minions are there like in a second. Are there specific tools for that?
_jezell_ 8y ago
Nice to see someone finally do this. I love the Gitlab team.
- jahlove 8y ago
  as i read it they're not doing it
eire1130 8y ago
I wanted to respond to this thread in general as someone who runs a team that uses Mercurial for most of our work. But first, the proposal above, in my view, isn’t core mercurial, which is what most of this discussion is centered around. This is mercurial with evolve + topics, which has differences to what many of you are familiar with. With evolve + topics, many of the critiques of mercurial go away: * Light weight branches for short development * Ability to squash / fold - mutability * Ability to rebase - mutability With this class of features, you get the major product differentiator that git offers (light weight branches that are simple for collaboration). Therefor, if you value some of mercurials core features, and your primary value from git is the light weight branching model, mercurial with evolve + topics starts to look like a real solution for many shops. That is why this proposal is important and stands out from bitbuckets offering. Bitbucket (For now) only offers first class evolve support (in beta). With that said, we use mercurial in production for our main repository. We do use evolve + topics for our development and when commits land in production, those commits become “immutable”. Topics were very much a game changer for us when we started using them about a year ago. We had previously used bookmarks for collaboration and that situation wasn’t really viable. Like most people reading this here, our development team targets mostly web development. Most of our dev lives in one repo and generally we target a deploy per day, or multiple per day. We aren’t “continuous delivery”, but we are “effectively” “continuous delivery”. We have a straight forward workflow. We have a Topic per Jira ticket. That Topic gets cut from the head of the branch “default”. Developers work in these "feature branch" through the features lifecycle, sometimes these are big things (multiple week - big changes) and sometimes small things (hours or days worth of work). Developers can rebase their work, if they wish, and they can squash, if they wish. I generally discourage the later as I’m a believer more commits the merrier. I’m also not allergic to merging and I don’t see the value in a purely linear history, so rebasing isn’t as common for us. We also have a single integration branch. When developers are ready, we merge to this branch and the ticket gets advanced to qa. Once the ticket passes qa, we merge to default (therefore advancing the head) and the topic is closed out on its own. So with the above as a brief overview of our process and workflow, I wanted to also talk about some of the pain points that mercurial has. Some of these aren’t necessarily caused by mercurial directly, and some aren’t even addressable (ie, if we were to switch to git, we’d have the same problems, or similar) Pain Points: * Tooling kind of sucks. The biggest argument now to use git is less git itself, and more that you are buying into an ecosystem. As an example, we use Buildkite for our CI. Getting this started required some hacking to make it work. Buildkite doesn’t “just work” with HG. That’s generally the tooling story. We can make some stuff work, but most stuff doesn’t “just work”. * Merges can occasionally still be painful in a collaborative environment when multiple devs are touching the same files and the same line numbers. I think this is an unsolved problem and probably will remain so until the universe cools to absolute zero. * Evolve is great and I use it all the time, but some of developers here complain that it isn’t as well documented as other pieces of mercurial. Benefits: * In my view, the UI is simpler. Our team is comprised of individuals of varying degrees of technical sophistication. For examples, our designers are not software engineers and don’t really need to understand what a DAG is. But they do need to commit directly to our repository, create topics without asking others, and really only ask for help when they did something wrong / got themselves in trouble * TortoiseHG. This is a great tool, and most people can get benefit from it. It has some support for topics. * All commits are kept for all time. Not everyone finds this valuable. I find this extremely valuable. Evolve handles the mutability question by “hiding” old commits and basically creating new ones. * Hg log, which was mentioned before as a burden, in my view is a huge benefit and feature. Most hg commands take a revset.
sras-me 8y ago
Glad to hear this. I hope one day I can go back to Mercurial without the fear of being singled out.

277 points by testcross 8y ago

I still don't understand why git became so popular in comparison to Mercurial. Mercurial seems like a much more friendly and sane system. I hope adding it to Gitlab will help its popularity.

LukeShu 8y ago
Having a local "bare" copy (to use Git's term; `hg clone -U`) of the Mozilla repo, I'd like to create a checkout of it (`hg clone`), and build Firefox from it. This results in 90 minutes of waiting with hg pegging one CPU core (CPU-bound, not disk-bound!), then a few minutes of hg actually writing files, then the actual build taking 60 minutes. In the git community, it was always taken as a sign that they were doing something right that `git clone` was faster than `cp -r`. I'm having a hard time not taking it as a sign that Mercurial is doing something wrong that `hg clone` is so much slower. edit: The saying was that `git checkout` is faster than `cp -r`, not that `git clone` is. The sentiment stands.
- voltagex_ 8y ago
  How is git clone faster than `cp -r`?
  - dleslie 8y ago
    It may be in relation to when you duplicate a repository. When you cp an active git repository you receive an identical file state; when you git clone you receive only what is necessary. Old objects, reflogs, et al aren't in the clone. A clone of an existing local repository may also make hard links, if your file system supports it.
  - simcop2387 8y ago
    My first guess would be that git is going to be faster since it won't be doing a huge number of stat() calls and similar to grab metadata about the files it's creating, instead git will have the data in a single data structure it can efficiently ask for it from. Of course the filesystem has this too, but git will have it in a single location and probably more compactly, leaving it able to do it all with fewer reads. Then it has the data in the files compressed so the read is faster too. All this should mean that git can get to writing the files faster than cp will.
  - LukeShu 8y ago
    http://gitolite.com/git-performance.html http://gitolite.com/git-performance.html (the obvious answer) https://apenwarr.ca/log/20080121 https://apenwarr.ca/log/20080121 (some more nuance)
- sometimesijust 8y ago
  I have pulled and built Firefox from scratch over Australian internet in less than half that time? In general I have found all Mozilla repos to be an order of magnitude faster for this type of operation than the equivalent Google/Chrome repos (not using build caches).
  - LukeShu 8y ago
    The actual network clone is faster than that. The slow clone that I'm speaking of is cloning from one place on my hard drive to another place on the same hard drive.
- ygra 8y ago
  Mercurial tries to use hardlinks to share as much actual repository data as possible when doing a local clone. Maybe that's the part that's interfering here. You can try using hg clone --pull instead of just hg clone, which will not do hardlinks. Don't have much experience with terribly large repositories in Mercurial, though. Those we have at work have maybe a few thousand files and less than 20k commits and they're not particularly taxing.
  - lwf 8y ago
    `git clone` will also use hardlinks by default. --local, -l When the repository to clone from is on a local machine, this flag bypasses the normal "Git aware" transport mechanism and clones the repository by making a copy of HEAD and everything under objects and refs directories. The files under .git/objects/ directory are hardlinked to save space when possible. If the repository is specified as a local path (e.g., /path/to/repo), this is the default, and --local is essentially a no-op. If the repository is specified as a URL, then this flag is ignored (and we never use the local optimizations). Specifying --no-local will override the default when /path/to/repo is given, using the regular Git transport instead.
- durin42 8y ago
  How long ago was this? And what OS? I know we're faster than unzip on some platforms, but IIRC we just found a pretty awful performance issue on...linux? I think?... that meant our parallelized approach to writing files was burning a ton of time in the kernel filesystem locks or something.
  - LukeShu 8y ago
    Just a few days ago. Parabola GNU/Linux-libre (like Arch Linux). On btrfs, if that makes a difference. From what I could tell, whatever the slow part is, it wasn't parallelized at all; of 16 cores, 15 were idle, and 1 was pegged at 100% (and very low disk-wait). I've been meaning to dig in to this more. I'd tried adding --stream, figuring that maybe it was re-compressing the entire repo; but that just lead to a warning about "server doesn't support streams" or something like that. I'll definitely try ygra's suggestion to try --pull, and if that doesn't yield good results, I'll actually dig in to the sources and see what's going on.
    - durin42 8y ago
      Sounds a lot like https://twitter.com/indygreg/status/1028097388261433344 https://twitter.com/indygreg/status/1028097388261433344 - I'm pretty sure Greg was working with hg when he noticed this issue. In any event, if you're enthusiastic about this kind of thing, we'd love to have more eyes on making hg checkouts consistently fast, even in the face of filesystems undermining those efforts. ;)
      - LukeShu 8y ago
        If it were just btrfs being silly, I'd expect the high CPU usage to be attributed to a kernel thread, not to the hg process. But we'll see :)
xtreak29 8y ago
I use hg at work and git for open source. I can agree that GitHub and GitLab add momentum to git. Bitbucket is the almost the only provider. I feel hg can do the same things like git but a lot of that power is hidden under extensions in hg. I also love git releases that add a lot of UX improvements. Git is also fast compared to hg due to python startup time and it's one of the reasons hg still remains on python2. There is some effort on reorganizing python startup layout which will lay the foundation for faster hg. I hope with GitLab support hg gets more support and visibility.
pjmlp 8y ago
Simple, Linux.
- another-cuppa 8y ago
  This is definitely part of the reason. Back when git was first released there was a huge amount of scepticism about whether anyone actually needed it, but lots of people used it anyway just because they wanted to use what Linus made for Linux. I think since then many people have realised that Linus was right and that git is good, but it just wouldn't have gained so much momentum without Linux.
  - akvadrako 8y ago
    I don't think people found git better than hg (or monotone), but it got a lot more attention (due to Linus) and using two different systems is a pain.
JoshTriplett 8y ago
Speaking as someone who used both Git and Mercurial, and who has used both to contribute to projects: Git's concept of branches as simple names for commits, and the ability to switch branches really easily within one checkout (rather than encouraging the use of multiple working directories) helped hugely. Mercurial grew the ability to do git-style branching later, but git had it from the beginning. Git has always treated performance as a first-class feature, and that has enabled certain types of workflows that Mercurial makes painful. Git is fast enough that many things don't feel like they take any time at all. Git integrated first-class support for carefully constructing and reworking a set of patches to be sent by email. Mercurial again eventually grew such support, but early on, it was much more insistent that all branches must be kept around, and by the way are you sure you don't want to push your development branch experiments up to the server and keep them there forever since you haven't merged that head into the mainline? Even later on, mercurial had more of the functionality people wanted but relegated it to "extensions", while Git shipped it out of the box. Take a look at https://walac.github.io/mercurial-for-git-lovers/ https://walac.github.io/mercurial-for-git-lovers/ (from 2015) for just one of many examples.
- hyperpallium 8y ago
  What is hg's underlying data model?
  - JoshTriplett 8y ago
    I'm not an expert in mercurial, and I'll defer to those who are. My understanding is that while Git stores a tree of objects indexed by hash (and then packs them into packs along with an index, which can be repacked arbitrarily later on), Mercurial's primary data format is a log-structured list of revisions as deltas.
  - Zash 8y ago
    Abstractly, it's exactly the same as git. Commit → File tree → File data blob. The underlying data structures used are different, but considered an internal detail, so could be changed in the future. Today, most data is stored in a "revlog", where data can be either be stored (compressed) directly or stored as a (compressed) delta against an earlier version. Deltas may be chained. The index consists of fixed size records, which gives fast lookups, which are also linked to global revision numbers so that you can eg quickly find the commit based on a specific file change. Obs: This is based on attempting to re-implement the basics of Mercurial from scratch.
paulwithap 8y ago
I think git became dominant because there's no MercurialHub
- JimDabell 8y ago
  Bitbucket was the Mercurial equivalent of GitHub.
  - ksec 8y ago
    I think Github was way better than Bitbucket in its early days.
- weberc2 8y ago
  This is the correct answer. For some reason, the top-voted comment is some nonsense about Git's branching, which was never something I've desired or every found useful in a decade of rigorous daily use with both. To the contrary, git's branching model still trips me up all the time, specifically when I want to do things like list all the commits in the branch. Basically the problem is that unlike Mercurial branches which are actually branches while git branches are just a pointer to a particular commit. That pointer has no knowledge about what other commits are in the branch and the pointer can be moved anywhere across the tree (even to unrelated commits) with ease. Apart from the reflog, it's basically not possible to ask about the set of commits in the branch. The best you can do is never ever move the branch pointer except forward and make a note of the branch that your branch branched off of so you can do things like `git diff my-branch..parent-branch` (`hg diff -b my-branch` iirc). And this is just one of dozens of git warts.
rimliu 8y ago
As someone who did a presentation on DVCS for the local PHP devs in 2008 I have no problem understanding that. I covered Git, Mercurial and Bazaar. Even back then I predicted that git will win. It might not look very user friendly, but the foundations were rock solid. Branches on Mercurial seemed very clunky compared to git's.
mprev 8y ago
The battle seemed to be between Bazaar and Mercurial for so long. Both were easy-ish to use and both were written in Python. Mercurial usually had the speed advantage but then git came along and wasn’t written in Python. Speed wise it blew Bazaar and Mercurial out of the water. It was harder to learn for someone used to svn, perhaps, but the sheer weight of both Linus and Linux made it hard to ignore. I think GitHub deserve a lot of the credit for git’s omnipresence, though. With Launchpad our aim was to create something bigger than “just” a code sharing site and fairly or unfairly both Launchpad and Bazaar were seen as too close to Canonical. Whereas GitHub picked up the mantle that Sourceforge had dropped and made something way more collaborative than Sourceforge but held onto the idea of being a neutral third party.
- inferiorhuman 8y ago
  Bazaar... now there's a name I've tried to forget.
  - stevekemp 8y ago
    I think my history went something like this: RCS -> CVS, CVS -> SVN, SVN -> Darcs, Darcs -> Mercurial, then Mercurial -> Git. Bazaar I had to use for interactions with Ubuntu, but never in a serious way. Similarly I used a few other things such as Visual Source Safe (shudder), SCCS, and even BitKeeper, but I think they were used quite shallowly.
- lake99 8y ago
  > Speed wise it blew Bazaar and Mercurial out of the water. Benchmarks for this are hard to come by, and are for versions that are considered quite outdated now. But from what little there is, there wasn't that much of a performance difference between git and hg. For example, see this: https://www.draketo.de/proj/hg-vs-git-server/test-results.html https://www.draketo.de/proj/hg-vs-git-server/test-results.ht...
  - mprev 8y ago
    Well, sure they’re outdated because we’re talking about stuff that happened at least ten years ago. As for benchmarks, I don’t have any but there’s plenty of anecdata elsewhere in this thread that echoes the idea that git had significant speed advantages over both bzr and hg.
vnorilo 8y ago
While I don't consider myself a wiz, I'm fairly proficient at both (was responsible for stuff like lfs and submodule reorganization on git in my previous job). I'm honestly surprised that someone adept at one would struggle with the other: you basically just need to understand the semantical differences in branching. On windows, hg plays much nicer with powershell (ok, so clean is an extension, otoh hg -nu | rm).
- philjohn 8y ago
  It's not even that - it's mostly just the commandline interface needing you to learn several arcane commands to do simple operations. Of course, if you understand the underlying data model, they seem far less arcane, but that's the problem with Git that Mercurial doesn't have - you really need to understand what's happening under the hood to get proficient at it, whereas Mercurial has a far saner interface that hides the internals under a better abstraction.
  - jazzyjackson 8y ago
    I agree with this, but OTOH, in my experience git actually has a nice smooth learning curve for a little while until you hit your first 'wtf did did I just do' snag. I just know on my team or 5 much less technical people, the concept of version control and how to do operations in Mercury was near impossible and it fell on one person to manage merging files with master. Also, this was a distance learning course where the head institution (MIT Media Lab) was keeping a central repo of every location's additions, and the changes made the repo so big that we had hard caps on how much data we could upload. Later on, it fell on me to introduce git to some colleagues. Just walking them through 'checkout','branch','merge','push','pull' got them on their feet and contributing to a repo. If they hit a wall, I could help detangle the knot, but at least we were in it together.
  - jgraham 8y ago
    I really don't think that mercurial is very good at hiding the internals. Consider a common operation; asking for the commit history. If you type `hg log` you get something very close to a prettified view of the internal datastructure by default; a list of all commits in the repository, in the order they were added, each annotated with a sequence id that's an index into the internal list. So a new user has to learn: * hg log by default doesn't tell them anything about the current code they're working on; it's just a dump of everything. To get the history of the current working copy they need to pass -f which they are learning in other contexts means "do something unsafe". * hg gives commits sequence ids that can locally be used in place of the commit sha, but must never be shared across repositories. In practice at Mozilla I have seen people run into both these issues, causing much unnecessary confusion.
bipson 8y ago
We used hg in a uni project once, since large parts of our team had never used a VCS, and on of our advisors urged us to consider hg. (This was around 2010, so I guess hg improved considerably since then.) Even considering the additional overhead, we switched to git after a few weeks since the repository was constantly broken, and the two of us that knew git and SVN were desperately searching for the consistency and tools we had in git. At least we could support the team from there on and make it work for them. Not the ideal solution, but the best available to us. So I totally understand why git is more popular than hg. Until hg could be considered mature enough for larger teams, git already had a huge following, IMO.
- lclarkmichalek 8y ago
  Given that all of Facebook's repository's are hg based, I think it's fair to say that is pretty mature for large team use cases
  - bipson 8y ago
    Facebook didn't use hg until 2012 or later. I was talking and only know about the state of hg in 2010/2011 and at that point, git was widespread, stable and widely more useful than hg for anything besides simpler/smaller projects, again IMO.
    - andrewshadura 8y ago
      Hg was pretty mature by 2007 when I started using it.
- mixmastamyk 8y ago
  I used hg for years before finally succumbing to git. Never had a single issue with hg.
MikusR 8y ago
In Windows Git allows to use non ascii letters for filenames.
simias 8y ago
I used Mercurial as my main DCVS (and even pushed it at work) for many years, but now I faced the fact that git won and use it for everything. I have to use git anyway, so I might as well not deal with two different workflows and use git exclusively. Mercurial was ahead of git for a long time as far as usability and documentations were concerned. I still think it's a better match than git for many uses cases. Mercurial makes the simple stuff simple and the complicated stuff complicated (although still achievable), whereas git is more of a mixed bag in my experience. Git was superior for very large projects with many contributors working on completely different features and sending each other patches by email (e.g. the Linux kernel) but in practice 99% of projects, both FLOSS and corporate, don't have this profile. Git is a formula one, mercurial is more like a comfortable Sedan, so to speak[1]. I think git made it mainly because it could boast hosting the Linux kernel development and all the cool kids were on github. [1] Which reminds me of this "Git is MacGuyver, Mercurial is James Bond" comparison which is probably widely out of date by now: https://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ https://importantshock.wordpress.com/2008/08/07/git-vs-mercu...
dekhn 8y ago
From chatting with various folks, I think git had some features before Mercurial did. I recently adopted hg and found it much smoother to use, but learned also that many of the features I depended on were added only very recently.
IshKebab 8y ago
I would say a combination of things: 1. Network effects of github becoming popular. 2. It's faster. 3. Linux uses it and it was written by Linus (must be good in some people's minds).
camgunz 8y ago
Ruby and Rails were big at the time, and those communities really took to Git. There was kind of a competition between them and Python, so maybe that had some influence on not picking Mercurial/Bazaar, but regardless I think it wasn't as grounded in technical points as we'd like to think.

marcinkuzminski 8y ago

For a self-hosted option please check out RhodeCode has the first-class support of Mercurial, including largefiles, evolve, phases etc.

alwillis 8y ago
Kallithea is fork of RhodeCode, fully supports Mercurial and Git and is open source: https://kallithea-scm.org https://kallithea-scm.org.
- marcinkuzminski 8y ago
  RhodeCode is open-source too and unfortunately looks like Kallithea is a dead project by now. It didn't have a feature release since 2015, only a few bugfixes.

Annatar 8y ago

Mercurial is much easier to understand and use than git, and for the most part has feature parity with it. The only drawback was the decision to implement it in Python, which makes it very slow for large codebases with gigabytes in binary files. However, I'm given to understand that core performance parts are being re-implemented in C.

stevekemp 8y ago
Several parts of mercurial are implemented in C. There is an ongoing plan to recode some of the core in Rust: https://www.mercurial-scm.org/wiki/OxidationPlan https://www.mercurial-scm.org/wiki/OxidationPlan
- Annatar 8y ago
  Recoding it in Rust would make Mercurial instantaneously unportable to any operating system which does not have a Rust compiler.
  - dmytrish 8y ago
    Hopefully, it would increase pressure to actually port it there or to use another compiler like mrustc[0] [0] https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
  - Bjartr 8y ago
    What kind of platforms would you be worried about missing out on. Rust platform support[1] looks pretty solid, but of course isn't that of, say, C, but in practice I am not aware of (but would love to learn about!) Use cases for running a vcs on more obscure platforms. [1] https://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html
    - Annatar 8y ago
      "I don't recognize your platform. Rust runs on Windows, Linux, Mac OS X, FreeBSD and NetBSD. If you are on one of these platforms and are seeing this then please report an issue, along with the following values: navigator.platform: SunOS i86pc navigator.appVersion: 5.0 (X11) To install Rust, if you are running Unix, run the following in your terminal, then follow the onscreen instructions. curl https://sh.rustup.rs -sSf | sh" ...and running that gives: curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure And I am running UNIX, a true, AT&T System V, Release 4.0 UNIX: Solaris 10 on i86pc. I don't want to have to give up Mercurial just because someone somewhere is trying to be trendy by rewriting parts of it in Rust, because he thinks that's all the rage now.

Walkman 8y ago

It's GitLab, not MercurialLab. Hope they realize this and refuse to merge. I really like shared tooling and knowledge, so if Git dominates everywhere, all you have to do is learn git and that's it. It's a significant overhead to learn yet another VCS just because it is a little nicer. I hate wasted efforts.

deleted 8y ago
[deleted]
hvidgaard 8y ago
Do you really want a dev environment where there is only one way of doing things?
- Walkman 8y ago
  Yes! Absolutely! So I can focus on innovating where it matters (the product I'm developing). It alao would mean those things would be extremely polished (because a lot of people affected and interested to make it good). Also I would not need to learn so much random stuff I don't really care about.
  - hvidgaard 8y ago
    You're free to choose a tool and use that so you can focus on the product. But only having one tool would be rather counter productive for the community as a whole.
  - rleigh 8y ago
    This level of rigidity would preclude the gradual adoption of newer workflows, and hence be a hard blocker preventing any improvement or advancement. I hesitate to criticise it, but I don't think such an environment would be polished. A frozen environment is one which can't be improved, so will naturally stagnate. You couldn't achieve a state of being "extremely polished" because those who cared to do the polishing would be denied the ability to do so because it requires change in order to do so.

krob 8y ago

Oh the irony, phabricator has had mercurial support since day one almost.

kjeetgill 8y ago
I'm unfamiliar with phabricator's history. What makes it ironic? Did it have both out the gate and meet criticism?
mappu 8y ago
I evaluated phabricator today for Hg hosting at $DAYJOB. Issues in Maniphest aren't "attached" to a Diffusion repo, so you can't use it as a Gitea/Github-style one-repo-one-project system; it's one-phabricator-one-project-multi-repos. Spaces help a little bit but not really. Dealbreaker for us - we'd rather retrain staff on hg->git (and lose the amazing TortoiseHg).
arunc 8y ago
Phabricator doesn't support fork model.

kjeetgill 8y ago

Hm. My understanding is that the git and mercurial worlds follow different workflows around branching, merging, forking, etc. Does that cause a huge impedence mismatch in the UI? Or will they converge? In the same vein, I wounder if it's possible for a single repo/history to be checked out with either tool. You clone with hg, I'll use git. We both merge with patches as a common language. Disclaimer: only use git

y4mi 8y ago
bitbucket supports both as well

erlend_sh 8y ago

For a strong contender to "next-gen DVCS", I recommend checking out https://pijul.org/ https://pijul.org/. Written in Rust and based on a sound theory of patches. If GitLab actually merges Mercurial, I sincerely hope Pijul is next.

mattbee 8y ago
That sounds identical to darcs' pitch - http://darcs.net/DifferencesFromGit http://darcs.net/DifferencesFromGit darcs was an absolute pleasure to use, right up until they got stuck on the "merge of doom" bug http://darcs.net/FAQ/Performance#is-the-exponential-merge-problem-fixed-yet http://darcs.net/FAQ/Performance#is-the-exponential-merge-pr...
- autopoiesis 8y ago
  I think pijul's algorithms avoid the "exponential merge problem", though I don't know the details: https://pijul.org/manual/why_pijul.html#better-conflicts-for-everyone https://pijul.org/manual/why_pijul.html#better-conflicts-for...
- WorldMaker 8y ago
  Pijul is definitely inspired by darcs and from what I've seen most of its team is very familiar with darcs.
sleavey 8y ago
On a shallow note, I hope the command is changed or aliased if this becomes mainstream - writing "pijul" at the start of every command is awkward on English keyboards given that all the letters are near to each other on one side. Writing "git" or "svn" on the other hand, the letters are spread across the keyboard and shared between hands.
- Already__Taken 8y ago
  You don't alias git to just g?

asdadasdadasdas 8y ago

Sounds interesting. Is GitLab still just a bunch of guys somewhere in Ukraine? What is the likelihood of "it was an amazing journey" scenario?

testcross 8y ago

I read a few articles about a new way to work with hg that appeared in the past few years. They were saying that we don't need to have names on every branch. That actually we don't need to name many things and it works much more smoothly. I wonder what is the opinion of hg users here.

MordodeMaru 8y ago

Who other than FB albeit customized is using Mercurial in prod?

mi_lk 8y ago
JaneStreet I believe.
alwillis 8y ago
Mozilla.
- MordodeMaru 8y ago
  Really?
  - alwillis 8y ago
    Yes: https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/index.html https://mozilla-version-control-tools.readthedocs.io/en/late...
alwillis 8y ago
Nginx: hg.nginx.org/nginx.org

julia_lang 8y ago

Off-topic, but I think GitLab has incredible good (fast) marketing. If there's any inconvenience their CEO and his minions are there like in a second. Are there specific tools for that?

_jezell_ 8y ago

Nice to see someone finally do this. I love the Gitlab team.

jahlove 8y ago
as i read it they're not doing it

eire1130 8y ago

I wanted to respond to this thread in general as someone who runs a team that uses Mercurial for most of our work. But first, the proposal above, in my view, isn’t core mercurial, which is what most of this discussion is centered around. This is mercurial with evolve + topics, which has differences to what many of you are familiar with. With evolve + topics, many of the critiques of mercurial go away: * Light weight branches for short development * Ability to squash / fold - mutability * Ability to rebase - mutability With this class of features, you get the major product differentiator that git offers (light weight branches that are simple for collaboration). Therefor, if you value some of mercurials core features, and your primary value from git is the light weight branching model, mercurial with evolve + topics starts to look like a real solution for many shops. That is why this proposal is important and stands out from bitbuckets offering. Bitbucket (For now) only offers first class evolve support (in beta). With that said, we use mercurial in production for our main repository. We do use evolve + topics for our development and when commits land in production, those commits become “immutable”. Topics were very much a game changer for us when we started using them about a year ago. We had previously used bookmarks for collaboration and that situation wasn’t really viable. Like most people reading this here, our development team targets mostly web development. Most of our dev lives in one repo and generally we target a deploy per day, or multiple per day. We aren’t “continuous delivery”, but we are “effectively” “continuous delivery”. We have a straight forward workflow. We have a Topic per Jira ticket. That Topic gets cut from the head of the branch “default”. Developers work in these "feature branch" through the features lifecycle, sometimes these are big things (multiple week - big changes) and sometimes small things (hours or days worth of work). Developers can rebase their work, if they wish, and they can squash, if they wish. I generally discourage the later as I’m a believer more commits the merrier. I’m also not allergic to merging and I don’t see the value in a purely linear history, so rebasing isn’t as common for us. We also have a single integration branch. When developers are ready, we merge to this branch and the ticket gets advanced to qa. Once the ticket passes qa, we merge to default (therefore advancing the head) and the topic is closed out on its own. So with the above as a brief overview of our process and workflow, I wanted to also talk about some of the pain points that mercurial has. Some of these aren’t necessarily caused by mercurial directly, and some aren’t even addressable (ie, if we were to switch to git, we’d have the same problems, or similar) Pain Points: * Tooling kind of sucks. The biggest argument now to use git is less git itself, and more that you are buying into an ecosystem. As an example, we use Buildkite for our CI. Getting this started required some hacking to make it work. Buildkite doesn’t “just work” with HG. That’s generally the tooling story. We can make some stuff work, but most stuff doesn’t “just work”. * Merges can occasionally still be painful in a collaborative environment when multiple devs are touching the same files and the same line numbers. I think this is an unsolved problem and probably will remain so until the universe cools to absolute zero. * Evolve is great and I use it all the time, but some of developers here complain that it isn’t as well documented as other pieces of mercurial. Benefits: * In my view, the UI is simpler. Our team is comprised of individuals of varying degrees of technical sophistication. For examples, our designers are not software engineers and don’t really need to understand what a DAG is. But they do need to commit directly to our repository, create topics without asking others, and really only ask for help when they did something wrong / got themselves in trouble * TortoiseHG. This is a great tool, and most people can get benefit from it. It has some support for topics. * All commits are kept for all time. Not everyone finds this valuable. I find this extremely valuable. Evolve handles the mutability question by “hiding” old commits and basically creating new ones. * Hg log, which was mentioned before as a burden, in my view is a huge benefit and feature. Most hg commands take a revset.

sras-me 8y ago

Glad to hear this. I hope one day I can go back to Mercurial without the fear of being singled out.