Sunsetting Mercurial Support in Bitbucket
bitbucket.org
bitbucket.org
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) or Rhodecode open source edition. Kallithea is used by Unity engine to manage their source code internally with mercurial.
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:
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.
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.
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.
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/
dunno, I like git better, but at the time it did what our small team needed. Granted, we always ran into issues with one of us having a file locked that someone else needed, but onboarding was a breeze.
I'm glad I use git now, but Sourcesafe was an okay introductory source control solution.
Shared windows mount
Visual Source Safe
CVS
SVN
Perforce
ClearCase
Git
Team Foundation Server
Incidentally, I remember one person at Microsoft who claimed to be involved in the decision to adopt sd circa 1999 saying that Microsoft has the right to turn sd into a product if it so chooses. (He/she was responding to contrary claims made on an internal email mailing list which was very widely read, so I assume if he/she was misremembering or lying he/she would have been called out.) Though ultimately MSFT made VSTS/TFS version control instead, which has striking resemblances in concepts to sd/p4.
They called it "multiple checkout", and the manual strongly recommended you do not turn it on.
The software had issues with corruption due to operations not being atomic.
It was literally less functional than copying to a shared drive. Of course management and other developers refused to believe that OSS solutions were better, MS ecosystem developers were an extremely insular group.
What do you find difficult about it?
For the little while that I sometimes used Hg I found it much easier to get my head around.
It's mostly a lack of practice/use.
Watching hg and git grow up and compete as a darcs user was fascinating. Neither hg nor git had the elegance of the darcs UI (and arguably never will due to disparities in the underlying distributed code model), but it was clear from very early on that both hg and git were beating darcs on performance for large, active repositories. (Which was never a problem for a college student working on teams of maybe 1 to 3, but obviously a hard recommendation for the real world.) I experimented some with hg at the time because it had good Windows support, but had no reason to switch from darcs in college.
My first couple of jobs after college had me spending a lot of time in TFVC, and that eventually that lead to a much greater appreciation of git (and pushing teams to migrate from TFVC to git), and by that point TFS had already starting supporting git side-by-side TFVC, though ironically those same teams pushed hard for GitHub Enterprise. (Which does seem to underscore that git and GitHub really were so co-beneficial.)
By that point a lot of what hg had done right the git team was starting to pick up. At the very least, we should remember hg for pushing git to be better.
(As one example, someone else pointed to `git stash` as something that they didn't think hg had, but as I recall `mercurial queues` [MQ] was one of the earliest hg plugins, and MQ influenced the designs of both `git rebase` and `git stash`, and MQ itself was mostly deprecated by `hg rebase` and `hg shelve` which learned a lot from MQ.)
I believe those have been deprecated in favor of the evolve extension.
Mercurial is my goto for version control. However, in my experience, the information on the ideal tools/extensions is very scattered. The Mercurial book is 10 years old! For example, few mercurial users make use of branches for throwaway work - they use bookmarks. But how is a new user supposed to know that?
All the documentation I spotted currently still lists evolve as "experimental", and that doesn't help with any confidence of which tools/extensions to use in day-to-day operations, on top of how scattered the documentation is. It is interesting, perhaps how hg has a better UI, but git has always had arguably more consistent documentation.
(Similar too, both hg and git are built as sets of "plugins" to the core CLI but hg requires much more explicit installation and git just bundled a lot of them directly together and implicitly runs anything that even looks close [any script in the PATH that fits git-command may be run for git command], making it less clear which hg commands to use despite the better general UI, and easier to get started in git with a smorgasbord of commands.)
I somewhat remember the Named Branches versus Bookmarks discussion/confusion thing from the last time I attempted to use hg. It sounds unfortunate that it still doesn't seem very well documented or well explained this many years later.
I believe it is bug free, and fit for real world usage, and has been for years. If you read the details, the issue is there is a chance for performance degradation, and they consider that as "backward incompatible".
I'm sure it's changed now, but the lack of cheap fast branching was jarring.
I think many UI fetishists forget: Good UI helps begginer adoption but has to be incredibly way better to drive any readoption. But professionals will often have to suck it up and use a shitty UI if it means solving a technical shortcoming better.
So you end up using github as ui, even if you do not want to use a webpage
On my Skylake+SSD desktop, it takes over ten seconds to switch branches with git checkout, several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value.
We are making many great strides here at Microsoft to improve git performance, such as with VFS for Git which my Windows repo clone uses. But with hundreds of gigabytes in a unversioned download of the source tree, there is only so much we can do.
[1] since https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...
That one at least is fixed now, by having an option to disable it.
https://github.com/git/git/blob/v2.23.0/Documentation/config...
It would be interesting for someone inside Microsoft to write a blog describing why Git works well for the Linux Kernel but not for the Windows Kernel. They cannot be that different from a layout perspective, can they?
Some parts of Windows have split out into their own repos and CI build and test pipelines, but splitting is a process that takes people's time and has pros and cons, especially when changes in the main OS repo are needed to give the separated components a complete, coherent API surface.
https://github.com/Microsoft/WSL/issues/873#issuecomment-425... talks about why Windows I/O for multi-file operations is slow in general (as opposed to sustained I/O on a single file).
One of those is that path name lookup for certain file attributes is dirt cheap because of the dentry cache.
Since Windows doesn't have an equivalent, git is going to be slower there.
Hopefully the Microsoft people working on this will find ways to make git on Windows faster, since even with a much smaller repo (LibreOffice), git is somewhat painful on Windows.
WSL2?
It did not. We had a giant hg monorepo at Yandex, and even mere "hg id" took ages (and required net access to source repository for some reason). The plan was to eventually switch to it from SVN, not sure if they eventually did because I left the company.
Maybe these things have not proved true in the long term? I think Git turned out to have the better UI and architecture.
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.
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.
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.
What do you find easier to understand and explain about Git's model?
And great question about the Git model, after mentioning 'phases'! Mercurial has about a billion concepts and nouns for different random things like that. It takes forever to explain all the random ideas they've piled into it in an attempt to keep up with Git.
Mercurial think they can fix everything with yet another plugin and new concepts and nouns. Git built a cleaner model where you don’t need these plugins and abstractions.
Git copied things from Mercurial too. I don't think Git having a feature Mercurial didn't in 2007 means "Git turned out to have the better UI and architecture".
Git still has the problem Mercurial phases address.
A lot of Git users are annoyed that Mercurial branches work like other systems instead of Git and that it calls Git branches "bookmarks". New users understand Mercurial branches much more easily in my experience.
Mercurial queues are complex but only needed for workflows Git doesn't support. They're an extension so that most people don't even need to know they exist.
Do you have any other examples?
Because rebasing was literally an afterthought - a plugin. I don't think I ever push commits without rebasing them a few times. There's also now about six different ways to rewrite your history in Mercurial. It's a mess. Git has one way to do it and it's a normal part of the system.
If a Mercurial user asks me how to tidy up their history my answer is 'er... well there's rebase, mq, histedit, evolve...' that's a lot of options to teach people. In Git I just show them rebase.
It's all subjective isn't it? For me, less concepts, nouns, and plugins adds up to a simpler and so better architecture and UI. Maybe the extra concepts are what floats your boat and that's fine.
Hg extensions are just as much part of hg as the core functionality. It's just that they're opt-in parts many users don't need and thus don't have to see. If your workflow requires history editing, then fine, enable rebase and histedit.
As for mq, I think I've only used it in a script where I converted an ancient CVS repo and rewrote entire parts of the history to remove stuff that should never have been in there to begin with. It's powerful, but rarely required by anyone, and thus is opt-in as well.
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
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
git remote set-url origin <new URL> # Add new remote location
cd bar
git remote add neworigin https://newserver.com/foo/bar
git push --set-upstream neworigin masterI 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.
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.
I used to run Rhodecode some years ago, and switched to Kal when they forked. At this point I wouldn't be without it.
https://kallithea-scm.org/repos/kallithea/changelog
Now lets look at Rhodecode. 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.
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.
Kallithea is pretty easy to work with and extend. We recently updated and built a CI using buildbot. Rhodecode and Kallithea have diverged enough and are moving differently. Also its a Software freedom conservancy project so it will be supported, hopefully it can attract bit larger community.
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.
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.
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”.
Actually, it's like saying that those billions are comprised of a hefty number of people who tried both and the vast majority determined that overall git is an unquestionably superior tool due to a combination of the tool itself and it's ecosystem.
rumanator> [...] those billions are comprised of a hefty number of people who tried both and the vast majority determined that overall git is an unquestionably superior tool
The majority doesn’t determine every persons taste. Git is the dominant DSCM; it’s well represented. Why be so defensive if some minority likes hg semantics?
I think people tolerate Git because they really like Github.
I mean, I'll add to the pile of anecdotes this thread is accumulating but I don't know if it'll convince you that people are genuine:
I struggled to learn git, but it was also my first VCS. I've needed to muck with hg a few times and vastly prefer git. Hg was fine. It didn't win my heart or anything. But it also didn't let me (at the time) branch as quickly and trivially and it was slow as hell.
Sure, that need/want may not win a hg user to git, but I'd hardly call that tolerating git.
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.
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.
"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.
Not sure what that means?
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.
Again due to linus/linux community, git has amazing polish (efficiency, error messages, docs) of a superb data model and brepus user interface.
It was just the best development environment on windows
Mercurial was made for humans. It is seriously convenient and productive. Something I cannot say about Git, which more reminds me of an adhoc job.
I use both Git and Mercurial on daily basis. But my preference goes to Mercurial: it is just more sane in a big way. It is clearly a piece of art and love.
It's still probably slower for huge repos (I havn't checked), but I doubt it will bother you much nowadays.
I used Hg before Git professionally, because when they were both new, Hg had _much_ better Windows support.
That Github used this strange version control system cobbled together by the Linux kernel devs for their specific workflow was a bit weird, but that wasn't a showstopper for moving to Github.
After all it was just one amongst many version control systems, and a VCS shouldn't be the centre of the universe anyway, over time Github would probably offer different systems anyway after they become more popular.
Nobody expected that Github was essentially a Trojan horse ;)
GitHubs model is incredibly more viral and thus git won (sadly IMO).
i was using mercurial and svn before git. git was hard to learn but i went with efficiency and speed over convenience. also, if you have a good shell or a good GUI you don't need to memorize git commands. and if you are not a game developer uploading large binaries, git is the best around.
Hg was slow, and the (custom) python plugins around it we used were frustrating (specifically, we had a build pipeline that used the mercurial module in python, along with an arcane scons thing) and there were some specifically irritating pain points like bookmarks and shelve that didn't seem to work properly.
I mean, I get it, network effect... but all I can say is at least some people (like me) tried both and pick git on technical merit.
* Bitbucket provided unlimited free private repositories and they were exclusively Mercurial. Github had limits for private repos.
* Google evaluated both and preferred Mercurial for code.google.com http://www.saturngod.net/articles/dvcsanalysis-support-analy....
* Fogcreek (creators of Trello and Stackoverflow) picked Mercurial to power Kiln
Early on, both tools had different advantages but they evolved toward each other making the choice more about flavor and popularity. My guess is
* git was strongly associated with Linus so it won that crowd handily
* Github had a stronger association with open source than Bitbucket (dunno why though). Maybe it all came down to marketing. <-- there's a startup lesson
Maybe because it was bought by Atlassian.
Nope! Bitbucket had the "free private, paid public" model from the start. IIRC, Atlassian actually changed the model to allow unlimited public repositories after they purchased Bitbucket. It's possible that if BB had started with this model, they'd have been a much stronger competitor.
Early on GitHub gave out free public repositories, but Bitbucket gave our free private repositories. Working in public is aligned much more closely with open source than working in private is.
Hg has this way of actively pushing you towards the safe way of doing things (e.g. if you try to change history). Git will let you blow away a month's work if you mistype a command.
I get the impression Git is the popular option because it underpins the Linux Kernel and Android development processes. That means it's popular, not that it's perfect for every use case.
Mercurial is especially powerful when given to developers who know Subversion. A ~20% productivity boost just from being able to losslessly branch off and merge back without worrying about stepping on other devs' feed.
Another team found out about it and were interested, but ultimately deployed Subversion -- because having one authoritative repository in one place was important to their process.
What's the command to mistype?
I can't imagine having a month of work on a local machine that hasn't been pushed anywhere so it has to be something about pushing.
Fortunately, that can always be undone with another command
git checkout .
?It's sad to hear someone say that, presumably you've been bitten by it.
What you describe is not true. While it's easy to blow away work you haven't committed, every commit you've made in the past month is saved in the reflog. Going back to any one of them is as easy as finding it and typing git reset --hard.
Erasing something from the reflog is hard. Possible, but it's not going to happen by mistyping a command or two.
Makes me sad because of course I agree the git UI is terrible, and I don't blame any user for not being able to figure it out. Although Googling "how do I recover lost git commit" does pull up useful results.
This is bad enough. Git treats your workspace as trivial that can be replaced willy nilly.
Neither of us knew about Reflog at the time, so that didn't even get onto the list of things to try.
Management asked "what if you do that with Mercurial?"
Answer is, well, it won't let you do it without installing an extension. And the Wiki page for that extension contains a bunch of warnings about how you really should think long and hard about what you're trying to achieve -- and make as many backups as you can.
TRWTF of course is that my colleague hadn't pushed upstream for a month. Like I said -- former Subversion user. He didn't want his commit to mean someone else had to do a merge, and he didn't want anyone to see it until it was done.
Was "asking someone who knows how git works" on your list of things to try?
What about "learning how git works"? Was that on your list?
Frankly, you don't seem to have been trying very hard to get this work back.
I just had to write that rant out: https://wordpress.com/post/squarebits.wordpress.com/76
But if excavators were as hard to use as git, I'd never have mastered them.
If I can make an analogy.
There's little love lost on HN for C++. Anytime people mention C++ (possibly even here in this thread) people come out of the woodwork to talk about how hard it is to use, how it has too many features, blah blah.
I work in C++ every day. I don't think it's that hard.
When I have a question, I walk over and ask Chandler Carruth and Richard Smith. They are happy to help me debug my templates. Richard is the editor of the C++ spec, and Chandler is a well-known speaker, look him up on YouTube.
Over lunch we talk about new features of C++, we rant and gripe, and I learn.
Most people do not have Chandler and Richard in their life. Knowing them and the other experts on my team is a huge privilege. So when someone complains that C++ is too hard (wait for it, someone is going to do it here in this very thread...), it would be pretty insensitive of me to tell them that they should just ask someone who knows how C++ works.
Most of us in this thread do have someone in our life who is good at git, who helped us get started, and who saved our asses when we initially got stuck. Maybe that person isn't with us IRL, maybe that person is "just" a message board or IRC channel where we know we're welcome. But this too is a privilege.
If you've ever had trouble with anything and not had someone you could ask -- be it with C++, or real analysis, or whatever -- then I'd say you shouldn't throw stones at someone whose "whatever" happens to be git.
But try as I might, I cannot do so with C++ and git. They just make no logical sense to me.
Someone posts that they'd tried to join two strings in C++ and print the result. And they couldn't figure out how to do it; they would keep losing the second string. So, they gave up and changed languages, losing a month's worth of work.
Would you think that was reasonable, because they didn't have Chandler Carruth and Richard Smith available to help?
The thing I object to is judging them at all.
They're not my coworker, someone I have to rely on and therefore might be annoyed if they're unproductive or whatever. They're a random person on the Internet who rather humbly admitted to making a mistake out of ignorance.
Our "Git expert" was the one who blew away a month of work.
Mistyped as "git reset --hard HEAD~n"? git-revert is usually pretty nondestructive…
Don't you have backups? The companies I worked for had backups for all the home directories, so if I deleted something I could ask the admins to restore it.
If there are no central backups I would sure as hell set up a local backup, so there are more than one copies of my work in case something goes bad.
He is doing either some dangerous changes, which is not acceptable OR he is doing something that could be walled off by feature switch and integrated with at least weekly commits.
If it was some manager that told him to do that, fire that manager too!
...so you thought you lost a day's or a month's work, you didn't actually lose it.
You could just revert your revert commit, or check out an earlier revision.
I've heard this before. But since I seem completely unable to remember what a "reflog" is or how to use it, I always just copy my entire repo to another part of my disk before I do anything dicey with git (like rebase). This is of course ridiculous, but for me it's an easier workflow than "oh shit, I screwed up. Now I have to spend 2 hours on Google and SO trying to figure out how to get it all back."
From there you can grab the commit SHA1s and view their changes with `git show ${SHA1}`, cherry-pick them to your working branch, or whatever else you want to do to recover them.
No, it won't. It's much harder to lose work in Git than you think. But really, if your remote repository is setup correctly with protected branches, this should never happen.
So I have a local git push hook which blocks master pushes :)
I don't know if that's still an issue.
As an aside, it'd be perfectly legitimate for Mercurial (and git) to reject filenames that aren't representable in unicode.
I was surprised because we've been using it for years at work, sharing repositories between Linux and Windows, and we have never been bitten by this. Maybe the latin-1 subset of Unicode works? Or all the files we worked on just happened to have ASCII names (despite us being mostly non-Americans).
It's understandable that they would discontinue Mercurial support, but this part is shocking. No doubt that 1% includes more than a few obscure but historically interesting repos that will disappear because the owner wasn't monitoring their email (or is no longer with us).
Is BitBucket really that pressed for disk space? I hope they will reconsider and move those repos to a read-only archive like Google Code and CodePlex did instead of obliterating a piece of history for no good reason.
"""
* February 1, 2020: users will no longer be able to create new Mercurial repositories
* June 1, 2020: users will not be able to use Mercurial features in Bitbucket or via its API and all Mercurial repositories will be removed.
"""
The February 2020 deadline to prevent creating new Mercurial repos seems too late. Why delay? Ok, not next week by why not 1st November 2019. You will just upset randoms that by accident creates a Hg repo with bitbucket only to be told it will be deleted soon.
The June 1st 2020 deadline, is two parts. 1st part of disabling Hg features seems fine.
But as you say the second part should be punted way into the future if not never.
Sure, cripple it to read-only browsable only. But don't delete. There are plenty of tumbleweed open source projects that won't react before next year and be lost.
Read only browse means nearly all the same code, with whatever vulnerabilities it has, is there and needs to be supported. I'm sure a good chunk of removing the all Mercurial support is not needing to keep an eye on the code to allow repo browsing, etc.
"all Mercurial repositories will be removed"
does indeed sound quite at odds with why people use Bitbucket. dissonance re core value-proposition.
I hope Atlassian finds a less destructive way to phase out Mercurial support. Gladly they do have enough time to clarify / reconsider.
I remember back when I was at Atlassian and we had introduced Git repositories, Git usage grew an order of magnitude almost overnight.
Not sure what you mean. There weren't any git repos before so yeah usage of git grew. Or do you mean global usage of git, including outside Bitbucket? I doubt it grew an order of magnitude.
The funny thing is that github has an import tool. Since we are forced to move to the industry standard of DVCS, I guess many will use this opportunity to move to the industry standard of platforms as well. For my use case Bitbucket is now inferior or equal in all respects.
* https://insights.stackoverflow.com/survey/2018#work-_-versio...
where "zip backups" and network copy (each 7.9%) and "no version control" (4.8%) are higher than Mercurial (3.6%).
If you're in that boat, I can understand not using git (87%) because its UI sucks (IMHO), and not using SVN (16%) because it needs infrastructure, but Mercurial has neither of those hindrances. Heck, even RCS would be better than nothing at that point, and Hg is better than that.
https://gitlab.com/gitlab-org/gitlab-ce/issues/31600#note_19...
I've whipped together a script to help you migrate your repos to hg.sr.ht, for those interested:
https://hg.sr.ht/~sircmpwn/invertbucket
Let me know how it works out for you - I'd like to hear some test results before I post it to sr.ht-announce. Cheers :)
https://man.sr.ht/git.sr.ht/api.md
So you can create and manage repos over the API today. We're still figuring out a good API design for fetching hg data over REST.
1. `invertbucket` should check that the machine has `hg` installed. (I accidentally ran it on a machine that didn't.)
2. Say my sr.ht username is "thegreengiant" and my bitbucket repository is "abc". At the end of its run, `invertbucket` says:
> Imported to: https://hg.sr.ht/srht_owner/abc
That URL 404s. It would be an improvement if `invertbucket` replaced "srht_owner" with "~thegreengiant".
I really hope something happens to help hg start accumulating more market share. Not just for my opinion on the tooling; but because IMO the "git = github = the only place for opensource" monoculture is kinda problematic.
I love mercurial but also can see that the community is shrinking, mercurial still relies on Python 2.7, and we are approaching to the EOL of Python 2.7. TortoiseHG also suffers from this, and the release cycle is always out of sync with the hg releases, and this breaks thg. These little things shows the sad state of mercurial, and in the end, this will drive most of the developers away from using it.
I guess it was great while it lasted... now, Bitbucket, please provide the developers the right tools to move away from mercurial with celerity.
The releases being out of sync is not great, but if you're on Windows you download tortoisehg with a compatible hg, and if you're not your distro's repositories should ensure they don't push a new hg to you before tortoisehg is updated. I went and looked at the history, and the average delay from a mercurial release to the corresponding tortoisehg is only about 3 weeks. Not a big deal. On Arch Linux since tortoisehg isn't in the repos it's a slight pain to hold back mercurial. Hopefully after the Python 3 transition tortoisehg makes it into the repos.
...though if there is not mercurial hosting available by the time bitbucket sunsets support, then maybe I won't care. I really want to keep using mercurial for my public open-source projects.
> I went and looked at the history, and the average delay from a mercurial release to the corresponding tortoisehg is only about 3 weeks.
3 weeks for me is a lot of time, that's at least 3 weeks I can't use TortoiseHg, something I use on a daily basis. Anyway, since this happened several times now I manually update hg and thg to avoid this problem (but it's a PITA). I know this is a problem with the distributor and not from the Hg or Thg devs, but still it's a common problem that could be coordinated between the two projects. I actually started using Mercurial because Thg was way better than the Git GUI tools at the moment, and I think this still applies.
In conclusion, a hope the best for the Mercurial project but I'm afraid this will have a negative impact in the long term.
HG is by far the best UX of all SCM I have used. Without bitbucket I think usage of hg will drop even faster.
The sad thing is that git requiere so much arcane usage that hg have spared me for so much time.
I wonder why the worst always win? C, C++, JS, MySql.
Don't tell me is for "speed" or "features". Is incredible how much stupid effort and money go in put a lipsick on top of that when nicer ways exists... and are know... and have proved to work... and even faster (look at you, C/C++ build times)...
Even MORE bizarre is why not improve the tools coping what is good from others AND cleaning the usage of them?
Probably only python of the "good" side have critical mass...
Like what? I've been using git for 5 years and I hardly ever stray from the set {push, pull, reset, checkout, rebase}. I use VSCode for staging, committing, diffing, etc. though, so that probably spares me some commands, but I rarely (if ever?) have had to do what I would consider an "arcane" command.
> Even MORE bizarre is why not improve the tools coping what is good from others AND cleaning the usage of them?
Git has improved over time. Why, in the latest release they improved UX for the "checkout" command. Before it could mean "switch branch" or "restore file" but now there are 2 explicit commands: "git switch" (for switching branches) and "git restore" (for restoring files).
`git branch <branch name> && git switch <branch name>`
or
`git switch -c <branch name>` (create and switch)
https://palletsprojects.com/p/click/
Fundamentals in Git aren't necessarily easy to use from the CLI, but you'll get by with a dozen or so command line invocations overall. And I found it astonishing and disheartening how so many people were able to make do with completely illogical commands like "git checkout -b" ...
But once Git sticks you the finger and you _need_ to delve down into its guts, you often have a problem.
Now don't get me wrong, the amount of GUI tools hiding Git's intricacies and web interfaces like GitHub glossing over numerous shortcomings of Git have certainly helped the UX and the popularity. But once you _have to_ delve down to CLI usage because you ran into an issue that your tool tries to gloss over, most people are at a loss. And most people will opt to scrap the current clone+worktree and clone anew. That doesn't really sound to me like people are in command of their tool of choice (Git), though.
And at this point we haven't even touched stuff like refs which only differ in case. It's all fine until Git starts unpacking the refs. Which can be fun on systems like macOS and Windows which have support for case-sensitivity in the file system, but who opted to forgo that via a setting.
In this case it was speed. Git respected the time of it's users and hg respected the time of it's developers more, it's in no way surprising that users picked git.
> The sad thing is that git requiere so much arcane usage that hg have spared me for so much time.
IME the only people that struggle with git are people that refuse to learn it, properly learn it and not "pick it up as you go". It's such a small time investment that pays off for any professional.
Managers won't have to work with the tools they impose on their subordinates. It's the subordinates who have to. But I have also noticed how a lot of people profess to "like" Git for spurious reasons like because it's (allegedly) "so powerful", but then they stick to the simplest workflow possible, because they don't have a clue about intermediate or advanced uses. But that same logic can seemingly also be applied to why C++ "won" (not that I dislike C++ as much as Git, though). The charm is in how powerful it seems to be, but then you use loads of third-party abstractions and throw the alleged performance benefits out of the window.
For an SCM tool I want it to stay out of my way. It's meant to assist me in doing my main job. An SCM should not require my attention all the time because of the shitty CLI, inconsistent subcommands, horrible and incomplete documentation seeping with tool-specific terminology (see man gitglossary) and incomplete (or unidirectional) support for important features (git clone [here] [there], git push to remote with worktree).
Git manages to always require ones attention, and typically in the worst way possible.
However, I keep talking how we need to avoid monocultures, so I guess it is about time I assume some minor risk.
Sourcehut has accepted no external funding and once the alpha period ends, all accounts must be paid. Even with optional payment, it already turns a profit. I'm pretty confident in the sustainability of the service.
As for me losing interest, the good news is that I need software hosting no matter what I'm working on, so I'll always be working on it. And, since it's open source and patches are welcome, so could you add anything you need.
I wonder if Mercurial would have won if it was implemented in C or Rust (had it existed then).
For me, and I suspect for a lot of developers, the single biggest advantage of git is that it is fast.
Which I would find mildly ironic, because Linus initially was one of the last prominent holdouts against version control systems, and then made (in my opinion) a very ill-conceived decision to go with a commercial version control system that effectively made it harder for non-prominent, non-paying developers to contribute.
So when he decided to build his own version control system, I'd say it was not a foregone conclusion that he was a particularly qualified expert in the field. But in retrospect, the technical architecture underlying git has held up well (the UI maybe not so much).
I think there's a bit of that in Git vs. Mercurial. Git was built specifically for the Linux kernel and it shows. Most of its quicks and features make sense in that context. But the thing is, the overwhelming majority of projects out there are not anywhere similar to the kernel. They have fewer contributors, there are generally much more centralized, they don't use 90's style mailing lists, they don't deal with dozens of millions of lines of code etc...
I think for that "silent majority" of projects Mercurial was a much better choice indeed. It's simpler, for a long time it was much better documented, it was also easier to migrate from SVN and other centralized version control systems. But Git was cooler, it's what the kernel used, and if it's good enough for the kernel then it's good enough for me!
That being said at this point it's clear that Git has won. I've been slowly migrating my (active) projects to Git over the past couple of years. I'll have to use Git one way or the other anyway, I might as well try to uniformize my workflow. RIP Mercurial, you deserved better.
I wouldn't say Git has "won" or Mercurial has "lost". Hg still sees a lot of active development from the maintainers. As do Subversion, Perforce, and so on. Heck, ClearCase is as old as the hills and even that still has an active user community.
Python language used mercurial for quite sometime to manage all it's repository, they moved to GitHub not for performance but for inertia of mass adoption, knowing very well that git has inferior user interface and they need to rely on GitHub to make it work for them. Facebook, Unity engine still use mercurial.
Performance is such an important advantage, though.
I type git diff hundreds of times a day, and when I switched from hg to git at Mozilla, this made such a big difference in my life.
These days I type hg histedit maybe fifty times a day at Google, and I cry every time because it is so. glacially. slow. hg diff too. And I'm working with a relatively small repository.
Speed matters for tools we use all the time.
I'd also posit that the process of writing "plugins" for git is much easier than writing hg plugins. A git "plugin" is just a shell script that uses git. If you can use git, you can write a shell script that uses it. An hg plugin...whoaboy.
$ time hg help > /dev/null
real 0m0.232s
user 0m0.196s
sys 0m0.033s
$ time chg help > /dev/null
real 0m0.081s
user 0m0.003s
sys 0m0.000s
$ time hg diff
real 0m1.383s
user 0m0.558s
sys 0m0.333s
$ time chg diff
real 0m1.224s
user 0m0.003s
sys 0m0.007sThat's a big except. Mercurial was far too slow. Not sure if that's still the case; I haven't used it in years. But it was slow when the field was still open to competition.
In my last team we switched from Hg to Git and absolutely everyone but the CTO felt more comfortable with it. including the data scientists.
To me, Mercurial UI might be friendlier than Git's but it's really a moot point if it does not fit with the way people actually think/work.
Also, I sincerely think Git was getting more popular _before_ Github. Granted, it massified the adoption.
Still, at least SourceForge still has Mercurial support!
If Facebook tomorrow started saying they're totally going to stop being creepy and got a new CEO, I wouldn't suddenly start trusting them either.
Is that code for "must be under GPL"? I'm a BSD man myself.
It does not explicitly give out a list on that page (to get that you need an account), but from a read it seems to say GPL-compatible which BSD is.
The repository has a very explicit goal: The expressed purpose of advancing free software that can run in free operating systems. Licenses aside, the answer to the question if a project is suited for Savannah is likely answered by looking at that goal.
I suspect that they are working on improving their build pipeline and CI tooling and it's proving to expensive (perhaps in both time and money) to get that working reliably for both Git and Mercurial.
Not every feature helps you. There's a support burden with every line of code, and the support burden for another entire version control system is probably pretty high. Every new feature you add has to either be written for that second version control system as well, or come with a disappointing article explaining why not.
If anything, this has the potential to free up resources they can spend on creating a differentiator that engages more than 1% of their customers.
Bitbucket seems more geared to teams working internally; finding projects on Bitbucket is hard.
To be brutally honest, I used Bitbucket because I had a grandfathered academic account (most features free). Github offers nearly all that I had on that account now.
Github is great for "social" coding, but Bitbucket is very clearly moving towards targeting insular, corporate development tasks. But then, with the price ticket on Atlassian's products, that's hardly a surprise. B2B is their bread and butter.
I used to use Jira extensively for my own internal projects (and, hilariously, my personal TODO list), but I'm moving away from that. I'm moving from my own personal server to a couple of Droplets, and I realised in moving JIRA across just how bloated it is. Most of the SCM integration tools I use are pay-for now, so for $10/yr, I'm getting less than I'd get with a Mantis or Bugzilla install.
I need to have a look for a new bugtracker. Custom Workflow support would be nice, that's really the only feature which kept me on JIRA for so long!
GitHub has offered an onprem server for some time now.
https://help.github.com/en/enterprise/2.16/admin/installatio...
It was a mess which was simply fixable by re-submitting the card details again.
They only had one job.
Then they (after it was sold) added git support and now they are removing hg.
More importantly, Bitbucket leaves the migration to you (if I read the article correctly). Once I download my repo and convert it to git, why would I stay with the company that just made me go through an annoying (and often painful) process, when I can migrate to Github with the exact same command? And why isn't there a "migrate this repo to git" button right there?
I want to believe that Bitbucket has smart people and that this choice is a good one. But I'm with you there - to me, this definitely looks like Bitbucket will die.
I prefer Mercurial to Git. I intensively used both for years and I can't say that Git is any better than Mercurial.
I do think they should at least come up with a plan to seamlessly migrate existing repositories to Git. Still, shocking.
I've always wanted to use Mercurial; I'd always found its user interface to be an improvement over git; as if it shipped with a great "porcelain" by default. I respect its ability to leak fewer implementation details while still offering plenty of power.
But I kept using git for all my projects, and GitHub with it.
Also, though I never found a reason to choose hg I had been told that it fit the Windows file system better than git. If so that wasn't enough.
It appears that in bitbucket enterprise cloud, there is no way for me as an administrator to prevent members of my team from making repositories public to the Internet. Is that true? If so I may need to look to on prem options, or perhaps GitHub enterprise cloud which seems to support better permissions. We deal in sensitive data so can’t risk an analyst publishing them to the net accidentally.
Is Bitbucket profitable?
Would be nice if companies were transparent about which products and services made the most money, rather than (best case, public companies) stating earnings for the whole company and breaking it out fairly opaquely through categorizations.
On the flipside I could see this being useful information to competitors, and instructive on which parts of your business to attack.
If Bitbucket is planning on actually removing Mercurial repos it seems like a good idea to crawl and archive those before that happens.
However the industry has voted by putting its weight behind Git and Git has won. It has caught up usability-wise. Its performance is miles ahead of Mercurial. While its underlying model is not straightforward to grok it enables great work flows.
Honestly I'm happy with Git and never looked back.
Article not found
The article you are trying to access is not available.
It may have been deleted or marked as spam.
May bitbucket and it's management forever have it sheets and stocks shorted. They deserve it.
Since I want my repos' outsourced and I'm being forced to use git, I am moving to GitHub.
Define: git - https://www.google.com/search?q=what+is+a+git
Several things seem really odd to me:
- They are ditching one thing that was a safe harbor from github.
- No migration path to Git inside bb service.
If I am going to migrate outside bb I might as well move away completely.
- Armageddon-style wholesale destruction of the old repos.
Could have left the read-only repos on a separate server. Or even just a tarball.
2) hg-git exists, and there's other things afoot that should be better
I use hg-git to put all my Mercurial based projects on Github.
But the last OpenSUSE update installed Mercurial 5, but left the old hg-git for Mercurial 4. Now it does not work anymore.
I used to use it all the time on linux.
Unfortunately the OpenSUSE update also removed it. Completely, it is not even listed in the package management anymore.
No one wants to maintain non-mainstream software
...and I just found it: https://github.com/tummychow/git-absorb
From HG's own documentation (https://www.mercurial-scm.org/wiki/ChangesetEvolution):
>While well on the way, the full implementation of the changeset evolution concept is still in progress.
HG's entire system requires far more investment in the tool than git will ever ask of you. And you probably don't need the feature in the first place. I consider changeset evolution a nifty feature, but it's also a devop smell in my book.
Evolution requires no effort whatsoever to maintain.
As far as smells go, its whole purpose is to make editing history less "smelly" than git's rebase -i followed by force push.
You are not a full blown development team, and beta software works for many people. That doesn't mean it's ready for prime time.
Jira may be the most comprehensive issue tracker (which isn't necessarily attractive -- but then they have Trello now, too), but on the version control and CI front I don't think Atlassian will have an easy time competing against Azure/GitHub/GitLab.
The common user just realized he or she needed more and demanded them for free.
The Enterprise market had DevOps features long before DevOps as term existed.
I guess hginit.com disappearing was a signal of things to come.
https://web.archive.org/web/20170320142857/http://hginit.com...
Hacker news, question: Have you ever tried mercurial? Don't you like to save keystrokes? Isn't `hg com` easier than `git commit`? Isn't `hg pul` easier than `git pull`?
Is there any way to shorten the amount of keystrokes to use git?
Sure, you can just set up aliases in your shell and in git. Set an alias in your shell for git → g and in git for commit → c and you can commit with `g c`.
https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases
I'm so used to "git co" and "git br" at this point (which are effectively analogues of the same commands on Hg) that I have to think for a minute when I SSH into a machine which doesn't have these set up.
Others have mentioned git aliases. But also, git recognizes some shortforms too. E.g. git rebase --con works the same as --continue. Doesn't work in hg.