A few months ago Bitbucket dropped the Stone Steps Webalizer project repository because Mercurial was no longer supported. Along with the source repository Bitbucket also dropped Wiki, issues, downloads and some configuration, like components and milestones, even though these didn't have anything to do with Mercurial.
I moved the project to another hosting service, but about a week ago I needed to follow up on one of the past Bitbucket issues and noticed that some images from the supposedly deleted repository Wiki were still accessible in Bitbucket cloud, which made me think that my repository was just disabled, but not deleted.
Here's your stuff back
I created a support ticket asking whether it was possible to recover repository issues. A rather helpful Bitbucket Support person responded with a download link to exported issues from the deleted repository and a suggestion to create another repository and import issues into the new repository. It didn't make much sense to create yet another repository URL, given that the old one was still being reported as gone, so, naturally, I asked if it was possible to just nuke the unsupported Mercurial repository and just reactivate the project with an empty Git repository, so they didn't have to do any conversion or importing.
The answer was that it was not possible, whatever the reason was. The next best thing then was to delete the old repository, so I can reuse the URL and Bitbucket Support did just that. I followed up with creating a new repository under the same project URL and imported archived issues. It was nice to get some history back.
This begs the question why did Bitbucket choose to drop entire Mercurial-based projects instead of just replacing Mercurial source repositories with empty Git repositories, so there's no contesting how repositories are organized, and preserving all issues, Wiki pages and downloads for those projects. I guess I will never know the answer for this one.
So, after a couple of days going back and forth with Bitbucket Support I had my issues back. I found the one that got all this process started and faced the question what to do with the new/old repository, given that I have the source in GitHub and builds in Azure DevOps.
My first thought was just to freeze the Bitbucket repository with a note that it is maintained only for historical reasons, but then I realized that Bitbucket has one invaluable feature that may come in handy in this project or any other project I may start - being able to create issues without any account, which is quite helpful for Open Source projects.
That settled it for me and here is where I ended up, as if it wasn't convoluted enough with GitHub and Azure DevOps.
Source code is hosted on GitHub, which does a great job with public access to the source code and issues and allows GitHub users create issues via a nice and simple interface.
GitHub Wiki, on the other hand, allows only link to images and provides no way to store them in the Wiki repository, like Azure DevOps Wiki does. I also find Azure DevOps pipelines more aligned with how I would like to build a project. Azure DevOps also offers more elaborate work planning and management, compared to GitHub's simplistic project cards. Finally, Azure DevOps offers release pipelines, which are quite nice for preparing a tracking release progress and can publish to GitHub downloads. Hence, I decided to stick with Azure DevOps for these activities.
Now that I got Bitbucket issues back, it got a bit messier for me, but nicer for everybody else in the sense that anybody can create an issue anonymously for this or some other project I may start, so this is where Bitbucket comes in.
It is somewhat ironic that all of this project activity is happening when the project was moved into maintenance mode, but it sort of happened and I decided to just go with the flow and see where it takes me, learning a few things about each of these services in the process.