Running a git server is a bit more challenging than running a traditional stateless web app because git is all filesystem centric. If you use NFS, pages that require many git operations can be very slow. Or if the storage servers have a low-level API some page loads might require many round trips and increased latency or long queues can make things bad.<p>Gitlab went thru a similar journey from NFS to a high level git api called gitaly:<p><a href="https://about.gitlab.com/blog/2018/09/12/the-road-to-gitaly-1-0/" rel="nofollow">https://about.gitlab.com/blog/2018/09/12/the-road-to-gitaly-...</a><p><a href="https://gitlab.com/gitlab-org/gitaly" rel="nofollow">https://gitlab.com/gitlab-org/gitaly</a><p>There are some other projects like this one that seek to address the problem:<p><a href="https://github.com/takezoe/gitmesh" rel="nofollow">https://github.com/takezoe/gitmesh</a><p>Git is already good and synchronizing between peers, but it's not low latency, so does require an extra management layer to make sure everything is correct.
This has been really frustrating me lately.<p>Sometimes I just want to quickly merge a small change (maybe a small config change, 1/2 lines) and then pull on master, branch off and start working again.<p>I'm regularly having to wait several minutes for the merge and while I know that there are ways around this locally it just annoys me that something so simple is taking so long.<p>This feels less like an apology and more like Atlassian saying "Us changing a platform which has worked a certain way for years and that breaking your workflow is YOUR PROBLEM. It's you looking at this wrong, merges have been asynchronous all along." despite our many combined millennia of experience being entirely to the contrary.
> our engineers implemented a solution where we would proactively<p>> our engineering teams prioritized their efforts to ensure that Bitbucket<p>It's not a coincidence that company that refers to "our engineers" rather than "we" is having basic engineering problems.
So they are migrating to an internal Atlassian Cloud and the production deployment (after 1 year of development) is hitting some performance issue.<p>Seems to be expected. Things rarely deploy flawlessly.<p>Sadly BitBucket isn't what it used to be ever since they dropped Mercurial and Microsoft acquired GitHub (and introduced the super generous Actions / build servers). I see no reason nowadays to recommend them.
>> Merging pull requests takes longer than it used to, but it is important to realize that merges happen asynchronously in the background and so you do not need to wait for a pull request to be merged. If you navigate away, it will finish while you are doing other things. We're updating the UX to make this clear.<p>This is terrible, sounds like this is the new norm. If I have to merge in 10 pull requests I can't wait 5 minutes per PR to see if there are going to be any merge conflicts, etc.<p>Ever since this popped up I'm seriously considering migrating everything away from bitbucket because of how slow merging is.
It seems like Bitbucket has always been the afterthought in Atlassian's stack. Are Bitbucket Cloud and Bitbucket Data Center still two separate code bases with different APIs?
So, bitbucket is not going to self-host, they're moving to an AWS based Atlassian product.<p>For many companies, it makes sense to use AWS (or a product based on it). For a company like Bitbucket, that is almost like if AWS decided to stop self-hosting, and use Google or Microsoft's cloud products instead, with their "product" just a wrapper on top of that. What is the point of Bitbucket, again? It's now a wrapper around a wrapper (Atlassian) around a wrapper. Except, it doesn't work that well.
This right here is why we will not be moving our Self-Hosted BB to their 'cloud'. I can't afford these kinds of outages and being 'small' we can yell and scream all we want and they won't care. I'd much rather have the control in my hands when something goes wrong. Goodbye BB!
I'm not certain, but my first glance at this would be that git is not a good candidate to move to a cloud, at least if you want to take all of the advantages of cloud architecture, as it is promoted by the cloud services.<p>You would have to think of some way of federating git repos onto local storage (local to the git process), to avoid network latency inside loops, etc. But maybe that's what Atlassian did and it still didn't work out, or maybe they thought of that but something else (have to fit into the Atlassian cloud architecture?) outweighed it.<p>Point being, you really need to design the cloud architecture around the way your hosted programs were designed to work.