Live data from Hacker News

Scaling in Bitbucket Cloud: new features and reliability numbers

blog.bitbucket.org

11–20 of 42 posts

Re: Scaling in Bitbucket Cloud: new features and reliability numbers

#11
post #9

The Bitbucket UI is a mess. * It takes over your native browsers find feature. * It's javascript heavy and has multiple panes that scroll, collapse, and expand. * Viewing diffs requires you to click each file that changed (unlike every other diff/code browser I've used where it has one long page with all the changes)

> * Viewing diffs requires you to click each file that changed (unlike every other diff/code browser I've used where it has one long page with all the changes) This is not my experience. Picking a random project I see a listing of all changes in all files: https://bitbucket.org/atlassianlabs/asap-cli/pull-requests/3... That's for a pull request, this is for a branch: https://bitbucket.org/atlassianlabs/asap-cli/branc…

I'm using the "enterprise" version, not the public version. Maybe there's a difference. And yeah, that view you posted is a lot easier to read.

Re: Scaling in Bitbucket Cloud: new features and reliability numbers

#12
post #6

I was recently looking at BitBucket Data Centre, to move our in-house git server to something with better clustering & high-availablilty & failover (rather than doing it ourselves). I was a little disappointed to find out the HA features are provided by storing your repos on an NFS server, and detaching/attaching it to the primary node.

Bitbucket PM here, sorry to hear this doesn't suit you. Could you tell me more? If like to better understand your concern.

Sure! We don't have any NFS infrastructure, so migrating to BitBucket means paying for the license + some kind of SAN + engineers to look after it.

We'd much prefer to use EFS but I understand that it's not supported, since there's no way to set `lookupcache=positive` (git push might update the ref to an object which may not be immediately available across all NFS clients & they would cache that the object doesn't exist unless this is set)[0]

[0]: https://docs.gitlab.com/ee/administration/high_availability/...

Re: Scaling in Bitbucket Cloud: new features and reliability numbers

#13

Earlier quoted context omitted.

Bitbucket PM here, sorry to hear this doesn't suit you. Could you tell me more? If like to better understand your concern.

Sure! We don't have any NFS infrastructure, so migrating to BitBucket means paying for the license + some kind of SAN + engineers to look after it. We'd much prefer to use EFS but I understand that it's not supported, since there's no way to set `lookupcache=positive` (git push might update the ref to an object which may not be immediately available across all NFS clients & they would cache that the object doesn't ex…

The real clincher is that if we can set up HA NFS, then we might as well migrate our existing git solution to it and save ourselves the license cost…

Re: Scaling in Bitbucket Cloud: new features and reliability numbers

#14
post #11

Earlier quoted context omitted.

> * Viewing diffs requires you to click each file that changed (unlike every other diff/code browser I've used where it has one long page with all the changes) This is not my experience. Picking a random project I see a listing of all changes in all files: https://bitbucket.org/atlassianlabs/asap-cli/pull-requests/3... That's for a pull request, this is for a branch: https://bitbucket.org/atlassianlabs/asap-cli/branc…

I'm using the "enterprise" version, not the public version. Maybe there's a difference. And yeah, that view you posted is a lot easier to read.

Can confirm. The enterprise (aka Bitbucket Server) version gives you a two pane layout, with files on the left and changes to those files on the right.

Re: Scaling in Bitbucket Cloud: new features and reliability numbers

#16
post #11

Earlier quoted context omitted.

> * Viewing diffs requires you to click each file that changed (unlike every other diff/code browser I've used where it has one long page with all the changes) This is not my experience. Picking a random project I see a listing of all changes in all files: https://bitbucket.org/atlassianlabs/asap-cli/pull-requests/3... That's for a pull request, this is for a branch: https://bitbucket.org/atlassianlabs/asap-cli/branc…

I'm using the "enterprise" version, not the public version. Maybe there's a difference. And yeah, that view you posted is a lot easier to read.

Might want to check and see how far behind you are in upgrades. Even though the on-prem version will never have feature parity (new features hit cloud first) it could be that whoever runs your instance hasn't upgraded in a little while.

Re: Scaling in Bitbucket Cloud: new features and reliability numbers

#17

Earlier quoted context omitted.

Sure! We don't have any NFS infrastructure, so migrating to BitBucket means paying for the license + some kind of SAN + engineers to look after it. We'd much prefer to use EFS but I understand that it's not supported, since there's no way to set `lookupcache=positive` (git push might update the ref to an object which may not be immediately available across all NFS clients & they would cache that the object doesn't ex…

The real clincher is that if we can set up HA NFS, then we might as well migrate our existing git solution to it and save ourselves the license cost…

I think they just announced that AWS is a first class supported platform (I'm here at their conference) so it might be worth looking again. Of course that might be Data Center products only so don't quote me on it. I'm sure someone from Atlassian is around here and can confirm.

Re: Scaling in Bitbucket Cloud: new features and reliability numbers

#18
post #11

Earlier quoted context omitted.

I'm using the "enterprise" version, not the public version. Maybe there's a difference. And yeah, that view you posted is a lot easier to read.

Can confirm. The enterprise (aka Bitbucket Server) version gives you a two pane layout, with files on the left and changes to those files on the right.

Bitbucket Server (formerly Stash) is a completely different codebase from Bitbucket Cloud. They share zero code. One is written in Java, the other in Python. It's a constant source of confusion. The naming is because of a terrible marketing decision. Atlassian marketing does all kinds of weird things, like advertising Bitbucket as only supporting git despite also supporting mercurial.

Re: Scaling in Bitbucket Cloud: new features and reliability numbers

#19
post #8
post #2

I've used and loved bitbucket for years for private project hosting, but for the occasion where I need to put more devs on a particular project I'm not sure why I would pay for it now over using gitlab for free. It might be different if it was 5 users per project for free, but 5 collaborators across all of my projects is just too limiting - especially when I can get everything bb has and more from gitlab. At the same…

Have you noticed any drawbacks to using Gitlab over Bitbucket/Github?

admittedly I haven't used gitlab to the extent I have with bitbucket/gitlab - but so far I haven't found anything missing personally - in fact there a lot of things in gitlab that I wish were in the others. A lot of the github enhancements lately have been things that gitlab had first.

The only real downside at the moment is for public open source github is still the place everyone is expecting you to be. Its hard enough for small projects to be noticed on github, putting them somewhere else means nobody will ever see them just browsing. But for private or private-for-now projects gitlab seems to be the best fit for me currently.

Re: Scaling in Bitbucket Cloud: new features and reliability numbers

#20
post #9

The Bitbucket UI is a mess. * It takes over your native browsers find feature. * It's javascript heavy and has multiple panes that scroll, collapse, and expand. * Viewing diffs requires you to click each file that changed (unlike every other diff/code browser I've used where it has one long page with all the changes)

I actually prefer bitbucket cloud to github. The pull request workflow in particular is a lot cleaner. Currently ditching both for gitlab tho.
Post reply on HN