Atlassian ending Mercurial Support in Bitbucket

Geir Nøklebye

World Builder
Staff member
Atlassian, the company that owns and operates the Bitbucket source code management service, has today announced they will sunset support for Mercurial source code management where Mercurial features and repositories will be officially removed from Bitbucket and its API on June 1, 2020.

How does this impact the viewers and OpenSim you might ask?

Linden Lab hosts all their viewer code repositories, including the required libraries in Bitbucket using Mercurial and not Git. Because of that the majority of third party viewer developers, including Dayturn, do the same, so this has potentially a major impact, at least in the short term.

Any existing code repositories will either have to be converted to use Git - a process that is both complicated and error prone for such a complicated project and set of interacting repository. At best it will lead to major disruption in progressing the viewer code, at worst valuable history and context will be lost in addition to the disruption.

Alternatives to converting to Git is currently unclear, and could include self hosting, but would have the effect of scattering repositories across multiple sites with differing functionality. It also adds another burden to developers managing hardware resources and backing up the repositories; tasks that were left to Bitbucket to handle.

Converting to Git would probably be a big advantage as both Apple and Microsoft has broad support for Git in Xcode and Visual Studio, so interoperability with both those two environments would be much improved.
 
Setting up a Gitlab with mercurial import should not be hard though. Unless the viewer code is a total mess... oh wait it is... well from what I read importing is not as much groundwork as it seems, at least the tools for it are getting more advanced by the day. Turns out a lot still runs on merc huh.

Alternatively for the time being could move to self-hosted sourcehut, I think that still has merc support.
 
Setting up a Gitlab with mercurial import should not be hard though. Unless the viewer code is a total mess... oh wait it is... well from what I read importing is not as much groundwork as it seems, at least the tools for it are getting more advanced by the day. Turns out a lot still runs on merc huh.

Alternatively for the time being could move to self-hosted sourcehut, I think that still has merc support.
I have it running on https://www.dayturn.com:5005
some 160 repositories

The issue with import to GitHub is you lose history and a lot of other things unless you set up extensive mapping manually.
 
Last edited:
Not only Bitbucket but also Python 2.
On Jan 1, 2020 it's over with pip install.
I'm curious how this goes on, because autobuild can
not stay that way if it does not work on Windows 10.
 
Not only Bitbucket but also Python 2.
On Jan 1, 2020 it's over with pip install.
I'm curious how this goes on, because autobuild can
not stay that way if it does not work on Windows 10.
In the TPV meeting on Friday LL was asked about autobuild, and Oz replied they did not regard autobuild as broken in any way, and were not prepared to do anything about it.
 
LL says autobuild works with Python 3, but you still have to be careful.
LL says the viewer can be built with Cmake and Visual Studio 2017.
cmake c: / viewer-release / indra c: / viewer-release
Open sln file in Visual Studio 2017
building

Conclusion: Nothing works as well as creating OpenSim with Prebuild and msbuild.
 
LL says autobuild works with Python 3, but you still have to be careful.
LL says the viewer can be built with Cmake and Visual Studio 2017.
cmake c: / viewer-release / indra c: / viewer-release
Open sln file in Visual Studio 2017
building

Conclusion: Nothing works as well as creating OpenSim with Prebuild and msbuild.
Knock yourself out! ;)
 
Stupid question: Is history really that important?
Less stupid question: Manual mapping? If there is something time consuming and boring, yet not all too complicated, than I have more than enough time to sit here click on things for hours :)
 
History is very important. Try debugging some issues without the ability to go back to see how it became to be (often in lack of other documentation). Also, unless you are a (special) SL TPV developer, you don't have access to SL JIRA.
 

Members online

No members online now.
Back
Top