1. 1

    I really like his workspace idea. I’ve sent one patch to three or four projects; there’s no need for me to have a whole clone of them up on github gathering dust.

    1. 1

      Would a PR from diff patch would be an interesting concept here ?

      1. 1

        Can you elaborate? I’m not sure what you mean.

        1. 1

          To this day, I’m surprised this isn’t a feature. I often only make one or two changes to a project, and would be happy to just push the refs (or create a patch) rather than forking and remember to garbage collect later.

      1. 6

        Great write up. I’d wish now for a Mercurial problem summary from him now just to lear what are the key problems in his opinion.

        1. 9

          Using nix to distribute RhodeCode was the best decision we made for how we distribute our software. It removed all problems we had with python packaging just using virtualenv. I think the key benefit is that our installation survives system upgrades while we had almost 40% failure rate in this case with previous virtualenv based installer.

          1. 5

            Would you be interested in doing a whitepaper?

            1. 3

              Do you instruct end users to use Nix, or do you have some custom installer that somehow hides Nix from the users?

              1. 5

                We abstract it. End users just run a single binary that creates full nix env, and unpacks all dependencies into a custom nix store.

                Nice things are that on upgrades we still have the full tree of old dependencies, so, for example, rollback to the previous release is just swapping a symlink.

                1. 1

                  This reminds me of the guix pack command: https://www.gnu.org/software/guix/blog/2017/creating-bundles-with-guix-pack/

                  Would something like that (e.g. ported to Nix rather than Guix) make life easier? I imagine that including Nix itself in the artefacts you distribute would make things quite bloated. (I’ve never used Guix, but I’m a big Nix fan :) )

            1. 16

              I seem to be the only person who moved from git to mercurial and liked git a lot more.

              Here were my impressions:

              • The index (“staging area”) is an awesome feature. I know it trips people up occasionally, but the ability to carefully and precisely stage some of the changes in the working tree is invaluable.
              • I like git’s branch model better than Mercurial’s. It’s more flexible and, at least for me, more intuitive. Maybe bookmarks are equivalent, but we didn’t use them at my work, so I couldn’t say.
              • I like git’s general acceptance of history rewriting. It’s a valuable feature without which you need to choose between committing very carefully or breaking bisect and having a useless history. If you’re worried about corrupting your history, back up your repository (which you should do anyway, history rewriting is not the only way to corrupt a repository). I know it’s possible in Mercurial, but it’s not a first-class citizen and the culture disapproves.
              • Mercurial’s commandline interface is a bit more uniform and predictable, but to be honest, this feels like a very weak benefit. If you’re using it professionally, muscle memory should basically mitigate the difference within at most a few weeks. Also, Mercurial’s interface certainly isn’t perfect, e.g. -l for commit limiting in hg log is wrong (it should be -n).
              1. 12

                index (“staging area”) is an awesome feature.

                hg commit --interactive or hg ci -i is essentially the same thing. What people generally like about the index/cache/staging-area (these were all official synonyms at one point) is the ability to selectively pick apart commits, not so much having an extra, semi-obligatory step between your code and the creation of a commit. With Mercurial’s curses interface, hg ci -i is pleasant and widely loved.

                If you really want a cache/index/staging-area, you can use hg ci -i --secret to start a secret staging commit and hg amend --interactive or hg am -i to keep adding to it. The --secret part is just to make sure it doesn’t get pushed accidentally. Once you’re ready to show the world your commit, hg phase --draft will turn it into a draft that you can share.

                I like git’s general acceptance of history rewriting.

                hg has this too, but better, and not as well-advertised: there’s a meta-history of what is being rewritten. This is called changeset evolution. The basic idea is that there are obsolescence markers that indicate which commit replace which other commit, so that history editing can be propagated in a safe, distributed fashion. No more need to force-push everything and then tell everyone who may have been following along to reset branches. Just push and pull and hg evolve will figure out where everything should be because it has more context.

                Mercurial’s commandline interface is a bit more uniform and predictable, but to be honest, this feels like a very weak benefit.

                My father, may he rest in peace, used to say that people can get used to everything except hunger. Sure, you can get used to git’s widely-derided UI. But why should you have to? If we can come up with a better UI, we should. Indeed, alternative git interfaces are their own cottage industry. Don’t downplay the problems that the git UI cause.

                1. 9

                  hg commit --interactive or hg ci -i is essentially the same thing.

                  No it’s not. I can (and frequently do) continue to mess with the working tree after adding changes to the index.

                  hg has this too

                  General, ecosystem-wide acceptance of history rewriting? Not in my experience. When I was using it, the general guidance seemed to be “don’t do that, but if you’re going to do it anyway, here’s how”, whereas guidance for git is more along the lines of “here are some things to be aware of when you do that, now have fun”. No remote solution I used would permit pushing rewritten history.

                  The very page you linked to says that evolve is incomplete.

                  To be clear, the workflow I’m looking to be enabled here is to commit and push extremely frequently—as often as I save, ideally—and then, once the feature is complete enough for review, squash all those mostly-useless commits together into a single or few meaningful ones. This lets me get both commits willy-nilly and meaningful, bisect-able history.

                  But why should you have to?

                  Because it took me like three days? “Not ideal” is a far cry from “compellingly bad”. I will certainly agree that git’s interface is not ideal, but Mercurial’s is not better enough to be a compelling feature on its own. (Also, I had to get used to Mercurial’s interface when I started a job that used it. Why did I have to?)

                  1. 9

                    No it’s not. I can (and frequently do) continue to mess with the working tree after adding changes to the index.

                    Have you tried hg ci -i? Combined with hg am -i, it really is the same thing. Creating a commit is, pardon the pun, no commitment.

                    The very page you linked to says that evolve is incomplete.

                    It’s sadly in a state of perpetual beta, but so was Gmail for about five years and that didn’t stop a lot of people from using it from day one. Evolve is mostly feature-complete, just not completely polished to the usual hg standards.

                    To be clear, the workflow I’m looking to be enabled here is to commit and push extremely frequently—as often as I save, ideally—and then, once the feature is complete enough for review, squash all those mostly-useless commits together into a single or few meaningful ones. This lets me get both commits willy-nilly and meaningful, bisect-able history.

                    This is exactly what evolve is for. And people can even pull your commits before they’re squashed and if they pull again after you squashed, they won’t even see the difference in their workflow. Their copy of the commits will also be squashed without them needing to do an extra step like git reset and try to figure out exactly what to throw out.

                  2. 4

                    I agree that the staging area is an unnecessary concept. As a self experiment, I made myself git aliases to not use staging. After a few months of using that setup, I can say that I don’t miss staging.

                    (I don’t use Mercurial at all)

                    1. 3

                      IMHO hg ci -i is a way better interface than git staging area even with -i. Used both, Mercurial one is way better.

                      However I just recently found that there’s a mercurial equivalent of hg -i for git too as a plugin.

                    2. 4

                      what benefit does the staging area give you that cannot be replicated by just committing the changes you would have staged and then doing a rebase to squash all the ‘stage’ commits into one main commit? I use this workflow a lot and find the intermediate stages cleaner and easier to work with than the git staging area.

                      1. 2

                        The index feels cleaner and if I wander away in the middle and forget what I was doing, it’s much easier to unwind.

                        Obviously, there are any number of workflows which provide equivalent functionality, and I doubt anyone can muster more than extremely weak objective support or criticism of any. Having used both git and mercurial, I strongly prefer having the index to not having it. If people push me on it, I’m sure I can rationalize that preference until the cows come home, but I’m not sure how constructive that would be.

                    1. 2

                      Glad to hear you’re enjoying Mercurial. Because I’m curious how they feel to a recent Git user: how do you like having local commit numbers that go 1, 2, 3, ... beside the usual unique hashes?

                      1. 3

                        I don’t use it that much but it is kind of nice to have a short hand, linear, way to look at the commits. Just talking about hash’s is pretty useless for anything other than knowing they aren’t the same.

                        1. 2

                          It’s nice to hear that you enjoy rev numbers, too. They are a detail, but one that I am fond of.

                        2. 2

                          Those numbers come in handy. E.g hashes don’t give you a perspective, you can tell quickly how big the project is looking at the numeric number, also comparing abcd...efgh vs 10...20 gives you much easier syntax to understand. Ofcourse this all applies only to local repositories because those numbers are relative

                        1. 4

                          If you don’t need hosted option but on-premise/private cloud you can check out RhodeCode which supports bookmark based Pull requests, Pull Request versioning, Mercurial evolve support.

                          Here’s our blog post on how to use bookmarks via Pull requests: https://rhodecode.com/blog/120/mercurial-workflow-using-bookmarks-how-to-setup-and-use

                          From our perspective using Mercurial to develop RhodeCode, a bookmark based workflow is a much easier to use than branches. And evolve/phases make it easier to simply rebase/reorder your commits, or fix small problems found during code-review.

                          1. 3

                            Evolve is one of the best feat. of Mercurial. We (RhodeCode) are shipping evolve extensions with fully enable per-repository support of it from the previous release.

                            What really surprised us is that lots of folks actually use it. We got lots of feedback and for sure we’ll update support for it.

                            1. 3

                              This article is great. Adds another area to think of when securing your company access.

                              1. 5

                                I also know that some startups offer below average salary, because of options you get as an employee when joining a startup.

                                1. 8

                                  This is kind of the same thing though, isn’t it? Options are worthless until there is a liquidation event. By not calling this out, the employer is hoping you’ll add the potential value of the options to your salary to get total comp, but they’re still underpaying you.

                                  1. 0

                                    Yes, exactly. It’s “virtual” money. It’s one of those things i don’t get why founder try to do such things to the employees.

                                  2. 8

                                    As I once said elsewhere:

                                    Stock options are for when you want to tightly couple your career and investing decisions at a moment when you’re excited and biased and trying to please someone who can offer or deny you a job.

                                    Before taking options, maybe ask yourself if you’d invest in this company if you weren’t going to work there.

                                    Personally, I consider stock options to be basically worthless, because:

                                    • Most companies fail.
                                    • Success or failure depends more on business decisions than on my individual code contributions.
                                    • Stock options can be complicated and sometimes employees get the short end of the stick vs outside investors
                                    • Having options would complicate my decision about when to leave a job for other reasons

                                    Getting paid in options makes me an investor in the business, and investing in individual stocks is always risky. Getting paid in cash means I have zero risk, and can invest in mutual funds or whatever seems prudent to me.

                                    1. 3

                                      True, the salary is lower but the expected value of the compensation isn’t usually different. Here’s how it works.

                                      Lets say you have a job that pays you $100k a year, no bonuses, and no option to buy into the company. How much do you expect to have been paid after four years, barring any promotions or raises? That’s $100k/yr * 4yr = $400k.

                                      Now suppose you have a different job. It only pays $90k a year, but you get to buy a .001 ownership stake in the company at negligible cost on a four year vest. There’s an 80% chance that the company will fail and go bust when it runs out of money after year four, but a 20% chance that the company could get sold outright for $200M. What do you expect to have been paid after four years?

                                      There are two possibilities. If the company goes bust, you get $90k/yr * 4yr = $360k. If the company is successfully sold, you get your $360k salary plus an additional $200k from the sale of your share of the company, for a total of $560k.

                                      Since you have probabilities for the two outcomes, you can calculate the expected value. You have a 20% chance of earning $560k, and an 80% chance of earning $360. (20% * $560k) + (80% * $360) = $400k.

                                      So the salary in the second job is 10% lower, but the expected pay after four years is exactly the same.

                                      What makes optioned offers so difficult to evaluate is the uncertainty in assigning the odds and payouts of success. Are the odds of liquidity really as high as %20, and will the company really sell for $200M? Or is it more like a 10% chance at a $500M sale? And is that better or worse? Expected value lets you weigh those options.

                                      1. 3

                                        What makes optioned offers so difficult to evaluate is the uncertainty in assigning the odds and payouts of success. Are the odds of liquidity really as high as %20, and will the company really sell for $200M? Or is it more like a 10% chance at a $500M sale?

                                        That’s my problem: either of those numbers could be anything.

                                        Also, imagine the stock and job being decoupled: you don’t work at this company, but you have the chance to invest $10k, with 80% odds of losing it entirely. Would you? I wouldn’t.

                                        you get to buy a .001 ownership stake in the company at negligible cost on a four year vest.

                                        Complication: what happens if you want to leave the job after 2 years? So far I haven’t had a 4-year job in tech.

                                        1. 1

                                          That’s my problem: either of those numbers could be anything.

                                          Like a lot of things, it takes explanation and practice to get a feel for how it works, but the numbers really can’t be anything.

                                          Its fairly common knowledge that nine out of ten startups fail outright. So a ten percent success rate is a pretty reasonable probability to assign if you know absolutely nothing else. The valuation range at liquidity is pretty limited too. A valuation higher than $500M would be outstanding, but $100M to $200M is a lot more common and a safer bet, again if you know nothing else. One way to get a better estimate than that is simply to ask what the founders think. They have to answer that question for investors all the time. Yes, it might be wildly optimistic, but at least you can use it as an upper limit.

                                          Also, imagine the stock and job being decoupled: you don’t work at this company, but you have the chance to invest $10k, with 80% odds of losing it entirely. Would you? I wouldn’t.

                                          Obviously if you can’t afford to be without the $10k for the investment period, or forever, you cant take that bet. But if we’re still talking about a payout on success of $200k with a confident 80% failure estimate, then the expected value math says its a good deal, and I’d certainly take it if I could afford to be without the $10k.

                                          However, those kind of deals (small, lucrative) are usually only made available to employees, as one of the benefits for doing work with the startup. If you evaluated the company and wanted in on the deal, but for some reason didn’t want to work there, you’d have to come up with a much bigger ‘put’ than $10k to buy into it. Think ten times that amount, if they wanted funding partners at all.

                                          Complication: what happens if you want to leave the job after 2 years? So far I haven’t had a 4-year job in tech.

                                          Most companies that aren’t on an immanent failure course will simply exercise their “right of first buyback” on your shares. You’ll get back whatever money you paid for them, and you’ll walk away from the job having made whatever your salary was for those two years.

                                    1. 3

                                      One of the SPA i really NOT enjoy using is cloud.digitalocean.com. I constantly keep refreshing the pages to make sure things are shown as I want.

                                      1. 10

                                        Main changes:

                                          Moby = open source development
                                          Docker CE = free product release based on Moby
                                          Docker EE = commercial product release based on Docker CE.
                                        
                                        1. 1

                                          I’d also add RhodeCode to that list

                                          1. 1

                                            I’d recommend looking at RhodeCode which supports Both HG and Mercurial (and SVN too). It’s feature ready, and mature enough to replace BB Server on premises.

                                            1. 5

                                              I was at the first day of this sprint. It was really interesting seeing so many engineers excited about mercurial development. Git may have the mindshare but mercurial is definitely not dead.

                                              1. 2

                                                I would like to strongly encourage y'all to do everything possible to make Hg as easy to use as possible. In particular, the floundering discussion on that etherpad about “friendly Hg” was discouraging. Right now git is (a) the defacto winner, and (b) a tire-fire of a codebase and © widely agreed that the porcelain is terrible, but nobody has the ability to change it.

                                                Hg is currently “waiting in the wings” so to speak, and many of us are following closely as Facebook and Google remove obstacles to us switching over to it as a sane monorepo-scale-capable substitute. Please, please, please keep in mind that the potential future users of Hg vastly outnumber current users. While it’s important not to lose community goodwill by churning things and giving people an expectation of version pain, it’s more important to get things right, and to get good defaults. I’ve watched Emacs users struggle with painpoints that 25 years ago weren’t changed “to not hurt existing users"… the future is long! :-)

                                                Also, fantastic work - I am waiting for Hg to reach the point where I can just stand it up, and have it work at company-wide-monorepo scale, and then I look forward to subjecting all my coworkers to the Glorious Monorepo :-)

                                                1. 1

                                                  The hg community is quite friendly. If you’d be interested in working on friendlyhg and know a bit of Python you should try sending in some patches.

                                                2. 2

                                                  On the contrary, mercurial seems to be the darling on the rise, doesn’t it?

                                                  1. 2

                                                    In this particular community, yes. Most of us favor simplicity, for our rather suckless-branded version of that, more than we care about being mainstream, and that means Mercurial has an outsized amount of support here. And Google and Facebook, for obvious reasons, are probably seeing Mercurial on the rise. But in general? Nah. Git won. (For now, at least.)

                                                    1. 2

                                                      I think in business around the world too.

                                                      • Academic is one of big user of Mercurial
                                                      • There are companies migrating from SVN still, and they actually prefer to switch to Mercurial because of CLI UX, and large files support which is far superior to GIT.
                                                    2. 1

                                                      Git probably has less mindshare among the people who care about the design decisions of the VCS they use. While this is a minority niche, it includes (although it is not limited to) most of the people who contribute to VCS development, and Mercurial does well enough in that niche to grow.

                                                    1. 3

                                                      It’s best to host your code repository yourself, this is what our focus was since few years. Open source code management such as RhodeCode or Gitlab is always better when it comes to privacy and security.

                                                      1. 6

                                                        While I definitely see the benefit of hosting your own repositories as a primary source, I would make the addendum that if you want to do this, you should have a mirror on GitHub. There’s a lot to be said for the centralized repository of open source code that GitHub has become, for contributors and users alike.

                                                        1. [Comment removed by author]

                                                          1. 2

                                                            I don’t know about gitlab, but RhodeCode is very easy to deploy as it has a great installer based on NIX package manager. You can have it running in minutes without configuring anything

                                                            1. 3

                                                              RhodeCode is very easy to deploy

                                                              Unless you are on a non-linux system :P

                                                              I recently tried to get RhodeCode up and running on OpenBSD - It doesn’t seem to be a trivial task. Is there something I am missing for other OS’s? or are they just not supported?

                                                              1. 2

                                                                We have a strict OS check in installer, we’ll look into this.

                                                                Btw, you can download the sources of community edition, and after installing nix package manager on OpenBSD, run nix-shell to see if it would work on your system

                                                                1. 2

                                                                  Unfortunately, the requirement to have an external package management system (outside of the ports framework) is another showstopper.

                                                        1. 1

                                                          we adopted a slimmer version of this around 2 years ago for our internal codes at RhodeCode, once you start pushing on the format reading commits will never be the same, and we believe even for the team of just a few people benefits are big.

                                                          You see those after some time only, when you have to read lots of commits, when you do a code-review etc.

                                                          1. 2

                                                            I hate generalization, and this is a perfect example of it. Our public instance of source code management uses robots.txt to prevent bots on hammering large repos like GIT or CPython. There are still many good examples of usage of robots.txt, and saying a general NO to them is not a good change.

                                                            1. 1

                                                              Really awesome, where can I find the source of their data?

                                                              1. 6

                                                                It is a very pretty map. If you look in the bottom right corner, you can select one of three display models, and there is a description of where the source data comes from and how often it is updated.

                                                                Short answer- ICON uses DWD (Germany), GFS uses NOAA (United States), and GEM uses CMC (Canada).

                                                                1. 1

                                                                  In case anyone else isn’t seeing this, the data-source widget isn’t shown on mobile (presumably to bring down small-screen HUD clutter), but it is on desktop.

                                                                  There’s a useful caveat in the HN discussion about these models, in that they’re generally fairly course-grained and laggy, so good for getting a general overview of global weather, but not for precise “nowcasting” of what will happen in your location within the next hour or two (or even what’s happening right now).

                                                                2. 0

                                                                  I belive it’s private data from the Czech meteorological company, see here: https://www.ventusky.com/about

                                                                1. 8

                                                                  Poor guys, but Github did it once too ! i remember they lost production database at some point.

                                                                  1. 2

                                                                    “Fast forward to today and there are still surprisingly few companies building software for teams.”

                                                                    The cobbler’s children have no shoes. There used to be a lot more money in the software tools market than today. Which is odd because software plays so much more of a central role in society and the economy now.

                                                                    1. 2

                                                                      there are few trends going on in software tools. First, this becomes a commodotized market. Secondly, there’s really big fragmentation here. There are companies just making code-review tools (as usual) but now even code annotation, pull request handling etc. I wonder if there’s not going to be a flip and we’re going to see more acquisitions and more defragmentation products like Gitlab which does lot in one product.

                                                                      That said, I believe there’s still a lot of nice things to do in this space, and this excites me :)