* 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)
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.
Feature parity is not really a goal of these products - they are totally separate teams, technologies and languages. If one team develops something awesome then of course the other will try to reimplement, but it's not really the case that features "hit cloud first".
You're saying the BitBucket cloud and server teams are using totally separate technologies and languages? That's not the impression I've gotten at all at every atlassian conference I've been to. Seems wasteful but nothing surprises me anymore.
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.
It sounds like you're talking about Bitbucket Server. This article is about Bitbucket Cloud. Some people (myself included) much prefer the Cloud product, some people love the server product - and often they have these opinions for the same reason. File-by-file diff is a good example of this :)
Disclosure, I work for Atlassian, but not on either of these products.
I'm a Bitbucket Product Manager. Thanks for the feedback! This is an area we plan to improve in the Server offering. In particular we're actively looking at ways to make diff nav and find much better.
We use Bitbucket (for over 4 years now) and in general like it mainly for its pricing model. However I have the (generally unfounded) fear that it will become bloated and slow like several other Atlassian products. I have really grown to dislike Jira but I will save that complaint for some other time.
The Bitbucket UI has improved over time but my real annoyance is the "Recent Activity" list is not wide enough and is not very configurable (ie filtering).
Also Bitbucket has sort of forgotten its Mercurial roots. Many Mercurial features have been added but it appears the Bitbucket UI does not show these features (for example Mercurial tracks moved files but Bitbucket does not show this).
The pipeline looks interesting but it is just a little too late for us since we are so heavily invested in Jenkins + Bash and will probably use Jenkins pipeline (Groovy) in the future. And if we do more opensource stuff it will probably be on Github so we will continue to use Travis. Also in all honesty I'm fairly sick of the whole YAML configure the world explosion... I actually miss XML but would prefer a scripting language over YAML (then again maybe I'm the only one who hates YAML).
Finally why is the Bitbucket blog so darn slow?
(I added this critique because I saw a Bitbucket PM floating around here).
> heavily invested in Jenkins + Bash and will probably use Jenkins pipeline (Groovy) in the future ... would prefer a scripting language over YAML
Do you really want to switch to Apache Groovy? Bash is pretty standard for scripting *nix whereas noone knows what the standard is for scripting the JVM?
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 time I understand bb needs to make money - hopefully they'll make enough to keep up the competition.
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.
Not OP, but as a majority user of Gitlab the only downside is integrations. By that I specifically mean Codeship. It's just not considered a first class citizen to some yet, which is unfortunate.
To be completely honest - probably nothing. This is a legacy issue on our end, not yours. I haven't even taken the time to explore migrating our GH/Codeship builds to GL CI. We essentially mirror our repos amongst both offerings at the moment, running builds via Codeship until either they support GL and we can drop GH, or we get the time to spend on a proper Codeship => GH CI migration and we can drop Codeship. Anyone's guess what will win out at this point :)
For us at Codeship, it has nothing to do with not taking GitLab seriously, not treating them as first-class citizen, etc. We'll add GitLab support, hopefully, sooner than later. There are simply other feature requests that are more important for existing customers that are already using Codeship.
Sure, and just to be clear that wasn't me straight griping. Completely understand you guys have priorities. Just doesnt change the fact that it's an existing pain point for heavy Gitlab users.
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.
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]
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.
Bitbucket user for many years now, and I was on the Pipelines Beta. Pipelines is pretty cool IMO - we set it up to automatically upload websites to S3 and invalidate CloudFront caches as soon as code is git pushed to BB.
Doesn't really matter that they've made Pipelines available for all users when it's lacking some pretty basic functionality. Like the ability to do something on failed builds.
But other than that it looks really good and responsive. Going to be interesting to see how the influx of new users will impact the average build time.
Hi vegardx, I'm the lead Product Manager on Pipelines. First of all, thanks for your comment. It's still early days for us but we've had some great feedback from beta customers and making it available to all customers allows us to help a lot more teams on Bitbucket. Regarding the failed builds you can use webhooks [1] today to trigger actions after the pipeline completes and we'll work on extending this capability in the future.
Our first focus was to make a platform that can scale on demand without hard constraints on the number of containers running. We know that we have some gaps to fill but we're now moving fast and we've added several features in the past weeks (repo status, notifications, pipelines statuses everywhere).
Thanks again for your feedback. Let me know if you have any questions.
Pipelines PM here. The model is a bit different, it's a pay as you go per blocks of 1,000 minutes. So if you normally use an extra 2,800 minutes per month you'll pay $30/month usually, but if for some reasons youd don't use it as much and drop to 1,500 extra minutes the next month you'll pay $20 for that month instead of $30/month every month of the year. For this reason we don't carry over minutes month to month.
I would like to carry minutes over. That would be far better for a solo developer like me, as I may need only 200 minutes a month, but I am stuck paying $120 a year in your model.
Much as I like Bitbucket I think either hosting my own CI and CD infrastructure on a cheap VPS or using gitlab is the way to go.
* 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)