Being a self-hosted product we have to make tradeoffs for the thousands of people operating (scaling, upgrading, configuring, troubleshooting...) instances. In short, we try to keep the system architecture fairly simple using available technology and keeping the broad skillsets of admins in mind.
It was a somewhat difficult call to add ElasticSearch for it's broad search capability, but being used for other purposes helped justify it. Adding Hound or similar services that were considered would have added more to administrative complexity and wouldn't provide for a broader range of search needs.
We continue to iterate on search, making it better over time.
Support for punctuation in search is something we knew wasn't ideal when we first added code search. As with all software, there were some technical constraints that made it hard to do.
We plan to have support for full stops and underscores in a future version and are exploring how to best handle more longer term. Our focus, based on feedback, is on "joining" punctuation character to better allow searching for tokens. Support for a full range of characters threatens to blow out index sizes, but if we get more feedback on specific use cases we're always happy to consider them.
Bitbucket Server PM here. I wanted to address some of these points as there's good news on many of them...
Regarding PR comments and line comments, file level comments have also been available from the beginning. There's a comment button above the diff view for this.
Regarding line comments being "lost", it's true that when they become outdated they can be harder to get to, but they're available. If you go to the activity tab all past comment threads are available to help make sure you've not missed anything. We're working on ways to show outdated comments in the diff view, and beyond that we're looking at adding more to our search capability for finding comments across pull requests.
For author and committer treatment, we do respect the two concepts in Git, but you're right that we don't display them clearly in the UI. We added coverage for returning both roles in the API back in 5.0, and at some point we'll probably update the UI to display it.
I'd love to hear more about what you feel is lacking in the diff view. We're doing some work there now so perhaps we can cover off your use case (or plan to already).
I think you've hit on a really important point. In isolation, a particular suggestion might be something of a papercut with a workaround. An unwanted pull request, for example, isn't going to stop others from getting their work done. But, if there are enough of these things that happen to affect a team together, it all adds up. It sounds your team is in that boat, and people not wanting to use the review functionality is a serious concern. Whether or not that's uniquely the case, I'd love to discuss further to make sure I properly understand your experience. If you're willing, please email me (rbarnes atlassian com) and we can set up a call.
We appreciate the frank feedback, but I have to disagree with the interpretation.
I really hate that we can't say yes to every feature suggestion, and what we _are_ able to talk about seems to come across as non-committal to some. The fact that a suggestion is open means we think it has merit too (we close "silly notions"), it then becomes a matter of priorities.
Sorry to hear you've been having trouble. What you describe is most definitely unusual so I'd suggest contacting us (or having your admin contact us) at support.atlassian.com so we can look into it.
The team has spent a great deal of effort over the entire life of the product to ensure it performs at scale for broad range of load profiles. The notion that we only recently had a very large instance for test is untrue. Perhaps someone got the wrong idea from our most recent series on how we build Bitbucket Data Center to _already_ support massive scale: https://developer.atlassian.com/blog/2016/12/how-we-built-bi...
For the first issue you mention, it sounds like you might be using an older version as this has been improved in a couple of respects in the last few releases. Specifically, the create pull request menu item (and it's siblings) are no longer collapsed in the sidebar. There is also a create pull request button on the pull request list page, and recently updated branches have a create pull request button on the personal dashboard shipped in Bitbucket Server 4.10.
Regarding frequent repos, I'm not entirely clear on where you're encountering this issue. If you send a screenshot to rbarnes atlassian com (spaces -> at, dot) I'll be happy to follow up with the team. We have some repo findability improvements in the works so it's a good time to make sure we haven't missed a pain point.
On the markup front, I hear ya. History makes it a little tricky to resolve in a way that will satisfy all, but we're looking at where editor UIs can converge to.
Being a self-hosted product we have to make tradeoffs for the thousands of people operating (scaling, upgrading, configuring, troubleshooting...) instances. In short, we try to keep the system architecture fairly simple using available technology and keeping the broad skillsets of admins in mind.
It was a somewhat difficult call to add ElasticSearch for it's broad search capability, but being used for other purposes helped justify it. Adding Hound or similar services that were considered would have added more to administrative complexity and wouldn't provide for a broader range of search needs.
We continue to iterate on search, making it better over time.