27 ms·

It's very sad to see bitbucket dropping mercurial support. Now only Facebook and volunteers are keeping mercurial alive. Sometimes technically better architect

It's very sad to see bitbucket dropping mercurial support. Now only Facebook and volunteers are keeping mercurial alive. Sometimes technically better architecture and user interface lose to a non user friendly hard solutions due to inertia of mass adoption. So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use. GitHub successfully marketed git, so git and GitHub are synonymous for most developers. Now majority of open source projects are reliant on a single proprietary solution Github by Microsoft, for managing code and project. Can understand the difficulty of bitbucket, when Python language itself moved out of mercurial due to the same inertia. Hopefully gitlab can come out with mercurial support to migrate projects using it from bitbucket. For people who believe in self hosted solution can install Kallithea (https://kallithea-scm.org https://kallithea-scm.org) or Rhodecode open source edition. Kallithea is used by Unity engine to manage their source code internally with mercurial.

kyrra 7y ago
Google contributes to Mercurial as well.
- dragonsh 7y ago
  I didn't know that, I thought Google is using customised perforce and later moved to Piper for their mono repository. I do not know if Piper still use some parts of mercurial or is based on mercurial. But it's good to know Google is supporting mercurial.
  - durin42 7y ago
    Piper still exists, but Mercurial is a viable client tool to interact with Piper's version history.
- zhengyi13 7y ago
  As do Facebook, if I recall correctly: https://engineering.fb.com/core-data/scaling-mercurial-at-facebook/ https://engineering.fb.com/core-data/scaling-mercurial-at-fa... That's from 2014, but I don't believe they've moved away from it since. In 2018, there's this: https://news.ycombinator.com/item?id=16565299 https://news.ycombinator.com/item?id=16565299
oaiey 7y ago
Just that git (w/o the central hosting/PR concept/issues) is the total opposite than proprietary, and despite the popularity of the social network GitHub (because that what it is) the market for hosting git repos is very active. Look at Gitlab, Bitbucket, Azure Repos, AWS, ... which are all just fine. I agree however with the fact that it is a pity to rely on a single tech which is not even the best of breed.
- strenholme 7y ago
  Another way to host Git code using 100% FOSS software is with https://sourcehut.org/ https://sourcehut.org/ and of course it’s possible to host your own GitLab community edition server as per https://about.gitlab.com/install/ https://about.gitlab.com/install/
  - yjftsjthsd-h 7y ago
    Sourcehut supports mercurial, too!
    - e_proxus 7y ago
      The UI is a hot mess though. Every time I try out their Mercurial site (it's actually a separate site, not just a feature of the main site) I always somehow end up on the Git part of the site and there's no obvious way back.
  - xvilka 7y ago
    Moreover, SourceHut also is the only system that supports[1] both FreeBSD and OpenBSD as CI platforms. NetBSD is coming soon too. [1] https://man.sr.ht/builds.sr.ht/compatibility.md https://man.sr.ht/builds.sr.ht/compatibility.md
jjoonathan 7y ago
I started my distributed version control journey when SVN was still king of the hill and git and mercurial were both tiny challengers. I actually picked mercurial first. I found the interface more intuitive, especially coming from svn. The problem was that everyday commands were just dog slow -- 5, 10 seconds on every single interaction. It felt like wading through molasses, contrast to git, which was effectively instantaneous on small repos and git on my large repo was still multiples faster than hg on a small repo. Also, IIRC hg didn't have a "git stash" equivalent. I chose git on its merits and didn't look back. A few years later (2010 ish?) I met a mercurial evangelist who said things had changed on the performance front, but I checked and they hadn't. I'll give hg the benefit of the doubt that it eventually got better, but I have serious doubts about your accusation that git's success had to do with marketing. I gave hg a more than even chance and it lost, fair and square, on technical merit, as weighted according to my everyday use cases.
- dragonsh 7y ago
  I started with CVS then moved to svn. From there moved to bazaar (bzr), from there moved to git and at last used mercurial and settled on it. I still keep an active look at fossil SCM. In my earlier team at fortune 100 firm, most developers use Windows with svn. We tried git and it did not work well due to UI and windows support. They were able to pick up UI easily and were quickly productive in mercurial. It worked pretty good on all 3 platform Windows, Mac and Linux. I am talking of time when GitHub was not that popular in corporate world. Performance was never an issue. Also at that time mercurial followed philosophy of being explicit and every merge needs to be explicit and committed with immutable history. So can see the evolution of code along with the mistakes made. I believe the success of git is due to GitHub and for many it's synonymous.
  - throw0101a 7y ago
    > I started with CVS then moved to svn. When I was your age we used RCS and SCCS, in the snow, up hill, in both directions. :) Seriously, I have no doubt git has an awesome on-disk format, but whenever I use the git(1) command I want to slit my wrists. I'm sure if a developer uses it many times a day it's possible to get used to it, but as a sysadmin that only uses it sporadically, I basically do: * git clone * vi repo/some/file/blah * git add/commit/push * rm -rf repo/
busterarm 7y ago
Unlike the VHS vs betamax comparison, Mercurial was not strictly-better than Git. Mercurial is quite slow in comparison and becomes brutally painful to wait for once your repo gets reasonably large.
chuckdries 7y ago
I don't agree with the assessment that betamax was superior. Sure it had more advanced technology, but it was too expensive and much more complicated - it fit the business requirements of a home video system poorly https://www.youtube.com/watch?v=ddYZITaxlTQ https://www.youtube.com/watch?v=ddYZITaxlTQ
ergo14 7y ago
I'm using RhodeCode, and so far it has been working great for both git and mercurial repo hosting - paired with Concourse CI it makes for a great combo.
chrisseaton 7y ago
> technically better architecture and user interface Maybe these things have not proved true in the long term? I think Git turned out to have the better UI and architecture.
- bch 7y ago
  > I think Git turned out to have the better UI [...] I think I have never heard that from anybody versed in git and any other distributed source control manager. Architecturally, we can look at (eg) speed performance and reasonable people could agree git leads or is a competitive contender. What UI examples is git bringing though? I’d love to love it, but to me it feels like a UI/UX disaster, and “getting used to it” is NOT an excuse when we have mercurial or fossil showing how much better it can be.
  - amluto 7y ago
    I like git’s architecture better — hg’s exposure of revision numbers needlessly tangles branches together and makes anything that creates throwaway commits messy. But git’s user experience is IMO gratuitously awful. Trying to keep track of all the various things that checkout and reset do leads mainly to frustration at the design. And I see no reason that use of the index should ever be required.
    - WorldMaker 7y ago
      Good news, in the latest git release checkout has two new friends that split checkout's functionality: switch and restore. Plus, they have much friendlier flags for knowing if they are affecting the index, the working tree, or both.
  - chrisseaton 7y ago
    Things like interactive rebase in Git are revision control UI innovations with a massive impact on my ability to deliver quality PRs. Git feels like a tool I can use to create and mould meaningful commits that best convey intent. Mercurial feels like it wants to just make a literal log of what I've done, which is a bit simplistic and isn't the same as what I want to present when my code is ready. I also find the model of Git much easier to understand and explain to others.
strenholme 7y ago
“a single proprietary solution Github by Microsoft” Moving (Edit: Just the code, not issues and not pull request information) away from GitHub is trivial, since Git itself is open source and distributed, requiring merely setting up a repo on the new server (such as the open source Sourcehut) then running these commands: git clone https://github.com/foo/bar vi bar/.git/config # Add new remote location cd bar git push baz master (Replace foo, bar, and baz with real names)
- ChrisSD 7y ago
  And what about the issue tracker? Issues and discussions of pull requests would be lost by merely moving the code.
  - strenholme 7y ago
    Some thing would be lost, yes [1] but the core code and commit history would be preserved. Issues can still be re-opened if still relevant, and pull requests can still be seen in the commit history. Comments on pull requests, if not approving a pull, will result in additional commits to the code which will be preserved. Whether this is OK for a given use case depends on how important ticket and pull request comment history is. For open source projects, I don’t consider that kind of history nearly as important as the code itself, since a lot of issues are wishlist requests, support requests, or downright spam. [1] Including branches unless one runs a script to go to and clone each branch to the new repo
  - michaelmure 7y ago
    I'm working on this, have a look at https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug
  - cabraca 7y ago
    you can import github projects including issues and stuff into gitlab https://docs.gitlab.com/ee/user/project/import/github.html https://docs.gitlab.com/ee/user/project/import/github.html
- 7y ago
hylaride 7y ago
As somebody that spent a lot of time trying to convince people that BSD was superior to linux and eventually having to give in when linux won due to various other reasons I know how mercurial fans can feel. I still almost choke on my own vomit whenever I have to do any networking in linux that's more complicated that setting an IP address.
- dragonsh 7y ago
  I like mercurial not because I am fan, but pragmatic and my team can work well with it. I still use it on daily basis. Indeed my team use hg-git and also git to work with GitHub for synchronizing some upstream repository of libraries we are using. Also you bring a topic of BSD, I used it since 1993 along with Linux and still use both of them. These days I don't use Solaris and other Unix though. In early years used various flavors of Unix like IRIX, AIX, HP-UX, Tru64 Unix and settled on BSD and Linux.
neandrake 7y ago
There's also Phabricator as a self-hosted (and open source) solution for Mercurial (and Git and SVN) repositories. https://phacility.com/ https://phacility.com/
philpem 7y ago
Another happy user of Kallithea here! I used to run Rhodecode some years ago, and switched to Kal when they forked. At this point I wouldn't be without it.
- wuboo 7y ago
  Kallithea was an option 2 years ago, now the development of it is basically dead. Rhodecode is still releasing regularly. Just check the feature differences: https://rhodecode.com/blog/133/rhodecode-vs-kallithea-comparison https://rhodecode.com/blog/133/rhodecode-vs-kallithea-compar...
  - dragonsh 7y ago
    Who says development is dead. Please check the changelog. https://kallithea-scm.org/repos/kallithea/changelog https://kallithea-scm.org/repos/kallithea/changelog Now lets look at Rhodecode. https://code.rhodecode.com/rhodecode-enterprise-ce https://code.rhodecode.com/rhodecode-enterprise-ce You will notice that Kallithea has been consistently updated regularly. Besides user like me its also used internally at Unity Engine. Also the features you mentioned not all are in Rhodecode open source edition.
    - marcinkuzminski 7y ago
      On a side note on this. I think Unity had their own fork of Kallithea with some changes that aren't in the official version ? Or those features are backported later from the Unity release
      - dragonsh 7y ago
        I believe some of the unity developers are constantly creating pull request to update Kallithea and are core developers. Can't say for sure but I think Unity's system Ono is using Kallithea as core with additional plugins developed for their own use.
    - wuboo 7y ago
pron 7y ago
> So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use. Marketing is often necessary to get a start, but it is rarely sufficient for a long-lasting success. The claim that "it's all marketing" is usually made by those who look at one aspect of the technical merits and miss others that turn out to be more important. Just as in the actual VHS vs. Betamax story [1]. Betamax had a slightly, almost imperceptibly better picture quality, while VHS had double the recording time of Betamax. VHS won on the technical merits as they mattered to users. [1]: https://en.wikipedia.org/wiki/Videotape_format_war https://en.wikipedia.org/wiki/Videotape_format_war
gwbas1c 7y ago
> So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use The real lesson is that once a technology looses, the people who invested in the looser will run around forever calling the looser better. In the case of VHS vs Betamax, VHS won because it was better overall. Some people point to one or two advantages of the Betamax format, but ignore that overall it wasn't better than VHS. (Because Beta tapes were physically smaller, you were usually forced to use a slower tape speed, loosing the very minor picture quality improvement at the highest tape speed. Thus, longer prerecorded Beta movies looked worse then their VHS versions.) The same thing is also the case with git versus Hg. I used Hg years ago because it was easier to learn; but once I learned git, I see no reason to go back to Hg. Yes, Hg has an easier learning curve, but that's one particular detail.
- woogley 7y ago
  I'm sorry to be pedantic but you've used "loose" incorrectly 3 times in a row. It's "loses" and "loser"
  - ryandrake 7y ago
    Not pedantic. English may not be OP’s native language, so tips like yours can be helpful. I found the rest of the comment to be insightful and true!
    - gwbas1c 7y ago
      100% native English speaker... And 100% dependent on modern spellcheckers.
      - deleted 7y ago
        [deleted]
- bch 7y ago
  > The real lesson is that once a technology looses, the people who invested in the looser will run around forever calling the looser better. I can’t speak for all “the people”, but I disagree strongly. There are fine reasons for picking things other than git (I’ve used fossil since it’s near-inception); git’s dominance or fossil’s loss in the market does not make gits UI/UX superior. Thats like saying McDonalds is the height of cuisine, because “Billions and Billions Served”.
wuboo 7y ago
As you said it's sad but fortunately we have Rhodecode. In my previous company I was using Rhodecode plus mercurial and for developer working with it was a pleasure. Now in current company we using Bitbucket, we'll think then to moving to rhodecode because we still want to use Mercurial
api 7y ago
Git won because it's superior in a way that many programmers think doesn't matter: performance. Git is incredibly fast. Many operations happen almost instantaneously even on large repositories. It's really nice. I've heard a lot of people talk about how they abandoned mercurial because it's slow. Some even switched to git from svn not because git's model is better but because svn is slower. "Premature optimization is the root of all evil" is an old programming advice quote that is so horribly misunderstood that it's basically wrong. It means think about your problem at the high (algorithm and overall goal / design space) level before worrying about low-level optimizations. It does not mean that optimization is bad or that performance isn't important. I made another comment recently on the same issue. I really wish that quote would die in favor of more substantial advice that won't be so misunderstood.
- benc666 7y ago
  "Premature optimization is the root of all evil" means: make it work correctly first, and then - if anybody cares - make it fast. Readability/maintainability, then only as needed trade it off for speed, because not all code needs to be highly performant.
  - api 7y ago
    Mercurial works correctly but is unbelievably slow compared to git. If you don't think about performance ahead of time (preferably at the algorithm level) then you will build something correct but slow and it'll be very hard to make it fast without redesigning major parts of it. It's possible to make design choices that paint you into a performance corner very easily, especially with something designed to work on a lot of data. O(n^2) might look like O(log n) for small data and in testing.
  - Shorel 7y ago
    From the Knuth paper: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." It means make it fast in the code that matters, do not try to make it fast in every single line. To say the quote is often misunderstood is the biggest understatement in modern computer science.
jimmaswell 7y ago
I've been using Mercurial and git for a long time and I have to say git's workflow is a lot better. Mainly Mercurial doesn't let me pull or do other stuff with outstanding changes, for no apparent reason other than that the author wanted it that way.
- mixmastamyk 7y ago
  > doesn't let me pull or do other stuff Not sure what that means?
  - jimmaswell 7y ago
    It just doesn't let me do things with changes in the working copy sometimes where git does. It's really annoying.
- pseudalopex 7y ago
  Mercurial lets you pull and even update with outstanding changes.
  - marcosdumay 7y ago
    And makes a mess of conflicts. I would rather not be able to do those things than to fix a conflict of a head with the working files on HG.
  - silverbacknet 7y ago
    This is one of my biggest pain points with hg vs git: Git is actually the one that flat-out prevents me from rebasing most of the time, usually for the most spurious of reasons, whereas hg just lets me choose to auto-rebase most files and pick the ones I'm interested in to manually merge.
zzzeek 7y ago
> So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use. this is an amazing opinion. Git won over mercurial because its capabilities and usage model are vastly better than that of mercurial. I had all of my projects on mercurial for many years and finally switched over to git, it was like a whole new world opened up. My daily workflows are now entirely based on concepts that are complete anathema to mercurial, where changesets are just objects that can be moved around or deleted once no longer needed, where commits to master represent complete features in a single changeset. Throwaway or hypotehtical branches are now changesets in Gerrit, rather than "feature branches" that exist forever whether or not they were used. I'm not sure if mercurial found a way to work out those problems of having zillions of little "fix typo" style commits crowding up a feature as well as zillions of dead feature branches forever crowding up the repo, but it at least was not apparent to me seven or eight years ago which would mean it's not easy to use.
- Blackthorn 7y ago
  It does: change evolution. It's very good.
hyperpallium 7y ago
Linus (and linux) was the key marketing; github and MS followed. Again due to linus/linux community, git has amazing polish (efficiency, error messages, docs) of a superb data model and brepus user interface.
benibela 7y ago
I still write my software in Pascal and store it an Mercurial repo on Sourceforge It was just the best development environment on windows

kyrra 7y ago

Google contributes to Mercurial as well.

dragonsh 7y ago
I didn't know that, I thought Google is using customised perforce and later moved to Piper for their mono repository. I do not know if Piper still use some parts of mercurial or is based on mercurial. But it's good to know Google is supporting mercurial.
- durin42 7y ago
  Piper still exists, but Mercurial is a viable client tool to interact with Piper's version history.
zhengyi13 7y ago
As do Facebook, if I recall correctly: https://engineering.fb.com/core-data/scaling-mercurial-at-facebook/ https://engineering.fb.com/core-data/scaling-mercurial-at-fa... That's from 2014, but I don't believe they've moved away from it since. In 2018, there's this: https://news.ycombinator.com/item?id=16565299 https://news.ycombinator.com/item?id=16565299

oaiey 7y ago

Just that git (w/o the central hosting/PR concept/issues) is the total opposite than proprietary, and despite the popularity of the social network GitHub (because that what it is) the market for hosting git repos is very active. Look at Gitlab, Bitbucket, Azure Repos, AWS, ... which are all just fine. I agree however with the fact that it is a pity to rely on a single tech which is not even the best of breed.

strenholme 7y ago
Another way to host Git code using 100% FOSS software is with https://sourcehut.org/ https://sourcehut.org/ and of course it’s possible to host your own GitLab community edition server as per https://about.gitlab.com/install/ https://about.gitlab.com/install/
- yjftsjthsd-h 7y ago
  Sourcehut supports mercurial, too!
  - e_proxus 7y ago
    The UI is a hot mess though. Every time I try out their Mercurial site (it's actually a separate site, not just a feature of the main site) I always somehow end up on the Git part of the site and there's no obvious way back.
- xvilka 7y ago
  Moreover, SourceHut also is the only system that supports[1] both FreeBSD and OpenBSD as CI platforms. NetBSD is coming soon too. [1] https://man.sr.ht/builds.sr.ht/compatibility.md https://man.sr.ht/builds.sr.ht/compatibility.md

jjoonathan 7y ago

I started my distributed version control journey when SVN was still king of the hill and git and mercurial were both tiny challengers. I actually picked mercurial first. I found the interface more intuitive, especially coming from svn. The problem was that everyday commands were just dog slow -- 5, 10 seconds on every single interaction. It felt like wading through molasses, contrast to git, which was effectively instantaneous on small repos and git on my large repo was still multiples faster than hg on a small repo. Also, IIRC hg didn't have a "git stash" equivalent. I chose git on its merits and didn't look back. A few years later (2010 ish?) I met a mercurial evangelist who said things had changed on the performance front, but I checked and they hadn't. I'll give hg the benefit of the doubt that it eventually got better, but I have serious doubts about your accusation that git's success had to do with marketing. I gave hg a more than even chance and it lost, fair and square, on technical merit, as weighted according to my everyday use cases.

dragonsh 7y ago
I started with CVS then moved to svn. From there moved to bazaar (bzr), from there moved to git and at last used mercurial and settled on it. I still keep an active look at fossil SCM. In my earlier team at fortune 100 firm, most developers use Windows with svn. We tried git and it did not work well due to UI and windows support. They were able to pick up UI easily and were quickly productive in mercurial. It worked pretty good on all 3 platform Windows, Mac and Linux. I am talking of time when GitHub was not that popular in corporate world. Performance was never an issue. Also at that time mercurial followed philosophy of being explicit and every merge needs to be explicit and committed with immutable history. So can see the evolution of code along with the mistakes made. I believe the success of git is due to GitHub and for many it's synonymous.
- throw0101a 7y ago
  > I started with CVS then moved to svn. When I was your age we used RCS and SCCS, in the snow, up hill, in both directions. :) Seriously, I have no doubt git has an awesome on-disk format, but whenever I use the git(1) command I want to slit my wrists. I'm sure if a developer uses it many times a day it's possible to get used to it, but as a sysadmin that only uses it sporadically, I basically do: * git clone * vi repo/some/file/blah * git add/commit/push * rm -rf repo/

busterarm 7y ago

Unlike the VHS vs betamax comparison, Mercurial was not strictly-better than Git. Mercurial is quite slow in comparison and becomes brutally painful to wait for once your repo gets reasonably large.

chuckdries 7y ago

I don't agree with the assessment that betamax was superior. Sure it had more advanced technology, but it was too expensive and much more complicated - it fit the business requirements of a home video system poorly https://www.youtube.com/watch?v=ddYZITaxlTQ https://www.youtube.com/watch?v=ddYZITaxlTQ

ergo14 7y ago

I'm using RhodeCode, and so far it has been working great for both git and mercurial repo hosting - paired with Concourse CI it makes for a great combo.

chrisseaton 7y ago

> technically better architecture and user interface Maybe these things have not proved true in the long term? I think Git turned out to have the better UI and architecture.

bch 7y ago
> I think Git turned out to have the better UI [...] I think I have never heard that from anybody versed in git and any other distributed source control manager. Architecturally, we can look at (eg) speed performance and reasonable people could agree git leads or is a competitive contender. What UI examples is git bringing though? I’d love to love it, but to me it feels like a UI/UX disaster, and “getting used to it” is NOT an excuse when we have mercurial or fossil showing how much better it can be.
- amluto 7y ago
  I like git’s architecture better — hg’s exposure of revision numbers needlessly tangles branches together and makes anything that creates throwaway commits messy. But git’s user experience is IMO gratuitously awful. Trying to keep track of all the various things that checkout and reset do leads mainly to frustration at the design. And I see no reason that use of the index should ever be required.
  - WorldMaker 7y ago
    Good news, in the latest git release checkout has two new friends that split checkout's functionality: switch and restore. Plus, they have much friendlier flags for knowing if they are affecting the index, the working tree, or both.
- chrisseaton 7y ago
  Things like interactive rebase in Git are revision control UI innovations with a massive impact on my ability to deliver quality PRs. Git feels like a tool I can use to create and mould meaningful commits that best convey intent. Mercurial feels like it wants to just make a literal log of what I've done, which is a bit simplistic and isn't the same as what I want to present when my code is ready. I also find the model of Git much easier to understand and explain to others.

strenholme 7y ago

“a single proprietary solution Github by Microsoft” Moving (Edit: Just the code, not issues and not pull request information) away from GitHub is trivial, since Git itself is open source and distributed, requiring merely setting up a repo on the new server (such as the open source Sourcehut) then running these commands: git clone https://github.com/foo/bar vi bar/.git/config # Add new remote location cd bar git push baz master (Replace foo, bar, and baz with real names)

ChrisSD 7y ago
And what about the issue tracker? Issues and discussions of pull requests would be lost by merely moving the code.
- strenholme 7y ago
  Some thing would be lost, yes [1] but the core code and commit history would be preserved. Issues can still be re-opened if still relevant, and pull requests can still be seen in the commit history. Comments on pull requests, if not approving a pull, will result in additional commits to the code which will be preserved. Whether this is OK for a given use case depends on how important ticket and pull request comment history is. For open source projects, I don’t consider that kind of history nearly as important as the code itself, since a lot of issues are wishlist requests, support requests, or downright spam. [1] Including branches unless one runs a script to go to and clone each branch to the new repo
- michaelmure 7y ago
  I'm working on this, have a look at https://github.com/MichaelMure/git-bug https://github.com/MichaelMure/git-bug
- cabraca 7y ago
  you can import github projects including issues and stuff into gitlab https://docs.gitlab.com/ee/user/project/import/github.html https://docs.gitlab.com/ee/user/project/import/github.html
7y ago

hylaride 7y ago

As somebody that spent a lot of time trying to convince people that BSD was superior to linux and eventually having to give in when linux won due to various other reasons I know how mercurial fans can feel. I still almost choke on my own vomit whenever I have to do any networking in linux that's more complicated that setting an IP address.

dragonsh 7y ago
I like mercurial not because I am fan, but pragmatic and my team can work well with it. I still use it on daily basis. Indeed my team use hg-git and also git to work with GitHub for synchronizing some upstream repository of libraries we are using. Also you bring a topic of BSD, I used it since 1993 along with Linux and still use both of them. These days I don't use Solaris and other Unix though. In early years used various flavors of Unix like IRIX, AIX, HP-UX, Tru64 Unix and settled on BSD and Linux.

neandrake 7y ago

There's also Phabricator as a self-hosted (and open source) solution for Mercurial (and Git and SVN) repositories. https://phacility.com/ https://phacility.com/

philpem 7y ago

Another happy user of Kallithea here! I used to run Rhodecode some years ago, and switched to Kal when they forked. At this point I wouldn't be without it.

wuboo 7y ago
Kallithea was an option 2 years ago, now the development of it is basically dead. Rhodecode is still releasing regularly. Just check the feature differences: https://rhodecode.com/blog/133/rhodecode-vs-kallithea-comparison https://rhodecode.com/blog/133/rhodecode-vs-kallithea-compar...
- dragonsh 7y ago
  Who says development is dead. Please check the changelog. https://kallithea-scm.org/repos/kallithea/changelog https://kallithea-scm.org/repos/kallithea/changelog Now lets look at Rhodecode. https://code.rhodecode.com/rhodecode-enterprise-ce https://code.rhodecode.com/rhodecode-enterprise-ce You will notice that Kallithea has been consistently updated regularly. Besides user like me its also used internally at Unity Engine. Also the features you mentioned not all are in Rhodecode open source edition.
  - marcinkuzminski 7y ago
    On a side note on this. I think Unity had their own fork of Kallithea with some changes that aren't in the official version ? Or those features are backported later from the Unity release
    - dragonsh 7y ago
      I believe some of the unity developers are constantly creating pull request to update Kallithea and are core developers. Can't say for sure but I think Unity's system Ono is using Kallithea as core with additional plugins developed for their own use.
  - wuboo 7y ago

pron 7y ago

> So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use. Marketing is often necessary to get a start, but it is rarely sufficient for a long-lasting success. The claim that "it's all marketing" is usually made by those who look at one aspect of the technical merits and miss others that turn out to be more important. Just as in the actual VHS vs. Betamax story [1]. Betamax had a slightly, almost imperceptibly better picture quality, while VHS had double the recording time of Betamax. VHS won on the technical merits as they mattered to users. [1]: https://en.wikipedia.org/wiki/Videotape_format_war https://en.wikipedia.org/wiki/Videotape_format_war

gwbas1c 7y ago

> So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use The real lesson is that once a technology looses, the people who invested in the looser will run around forever calling the looser better. In the case of VHS vs Betamax, VHS won because it was better overall. Some people point to one or two advantages of the Betamax format, but ignore that overall it wasn't better than VHS. (Because Beta tapes were physically smaller, you were usually forced to use a slower tape speed, loosing the very minor picture quality improvement at the highest tape speed. Thus, longer prerecorded Beta movies looked worse then their VHS versions.) The same thing is also the case with git versus Hg. I used Hg years ago because it was easier to learn; but once I learned git, I see no reason to go back to Hg. Yes, Hg has an easier learning curve, but that's one particular detail.

woogley 7y ago
I'm sorry to be pedantic but you've used "loose" incorrectly 3 times in a row. It's "loses" and "loser"
- ryandrake 7y ago
  Not pedantic. English may not be OP’s native language, so tips like yours can be helpful. I found the rest of the comment to be insightful and true!
  - gwbas1c 7y ago
    100% native English speaker... And 100% dependent on modern spellcheckers.
    - deleted 7y ago
      [deleted]
bch 7y ago
> The real lesson is that once a technology looses, the people who invested in the looser will run around forever calling the looser better. I can’t speak for all “the people”, but I disagree strongly. There are fine reasons for picking things other than git (I’ve used fossil since it’s near-inception); git’s dominance or fossil’s loss in the market does not make gits UI/UX superior. Thats like saying McDonalds is the height of cuisine, because “Billions and Billions Served”.

wuboo 7y ago

As you said it's sad but fortunately we have Rhodecode. In my previous company I was using Rhodecode plus mercurial and for developer working with it was a pleasure. Now in current company we using Bitbucket, we'll think then to moving to rhodecode because we still want to use Mercurial

api 7y ago

Git won because it's superior in a way that many programmers think doesn't matter: performance. Git is incredibly fast. Many operations happen almost instantaneously even on large repositories. It's really nice. I've heard a lot of people talk about how they abandoned mercurial because it's slow. Some even switched to git from svn not because git's model is better but because svn is slower. "Premature optimization is the root of all evil" is an old programming advice quote that is so horribly misunderstood that it's basically wrong. It means think about your problem at the high (algorithm and overall goal / design space) level before worrying about low-level optimizations. It does not mean that optimization is bad or that performance isn't important. I made another comment recently on the same issue. I really wish that quote would die in favor of more substantial advice that won't be so misunderstood.

benc666 7y ago
"Premature optimization is the root of all evil" means: make it work correctly first, and then - if anybody cares - make it fast. Readability/maintainability, then only as needed trade it off for speed, because not all code needs to be highly performant.
- api 7y ago
  Mercurial works correctly but is unbelievably slow compared to git. If you don't think about performance ahead of time (preferably at the algorithm level) then you will build something correct but slow and it'll be very hard to make it fast without redesigning major parts of it. It's possible to make design choices that paint you into a performance corner very easily, especially with something designed to work on a lot of data. O(n^2) might look like O(log n) for small data and in testing.
- Shorel 7y ago
  From the Knuth paper: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." It means make it fast in the code that matters, do not try to make it fast in every single line. To say the quote is often misunderstood is the biggest understatement in modern computer science.

jimmaswell 7y ago

I've been using Mercurial and git for a long time and I have to say git's workflow is a lot better. Mainly Mercurial doesn't let me pull or do other stuff with outstanding changes, for no apparent reason other than that the author wanted it that way.

mixmastamyk 7y ago
> doesn't let me pull or do other stuff Not sure what that means?
- jimmaswell 7y ago
  It just doesn't let me do things with changes in the working copy sometimes where git does. It's really annoying.
pseudalopex 7y ago
Mercurial lets you pull and even update with outstanding changes.
- marcosdumay 7y ago
  And makes a mess of conflicts. I would rather not be able to do those things than to fix a conflict of a head with the working files on HG.
- silverbacknet 7y ago
  This is one of my biggest pain points with hg vs git: Git is actually the one that flat-out prevents me from rebasing most of the time, usually for the most spurious of reasons, whereas hg just lets me choose to auto-rebase most files and pick the ones I'm interested in to manually merge.

zzzeek 7y ago

> So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use. this is an amazing opinion. Git won over mercurial because its capabilities and usage model are vastly better than that of mercurial. I had all of my projects on mercurial for many years and finally switched over to git, it was like a whole new world opened up. My daily workflows are now entirely based on concepts that are complete anathema to mercurial, where changesets are just objects that can be moved around or deleted once no longer needed, where commits to master represent complete features in a single changeset. Throwaway or hypotehtical branches are now changesets in Gerrit, rather than "feature branches" that exist forever whether or not they were used. I'm not sure if mercurial found a way to work out those problems of having zillions of little "fix typo" style commits crowding up a feature as well as zillions of dead feature branches forever crowding up the repo, but it at least was not apparent to me seven or eight years ago which would mean it's not easy to use.

Blackthorn 7y ago
It does: change evolution. It's very good.

hyperpallium 7y ago

Linus (and linux) was the key marketing; github and MS followed. Again due to linus/linux community, git has amazing polish (efficiency, error messages, docs) of a superb data model and brepus user interface.

benibela 7y ago

I still write my software in Pascal and store it an Mercurial repo on Sourceforge It was just the best development environment on windows