Is Atlassian developing features for Bitbucket Cloud AT ALL?

+1

+1

+1

+1

+1

+1

+1

+1

+1

Agreed - this is the only thing preventing us from migrating off of Azure DevOps over to BitBucket.

it has been 10 years sinces it was originallyc reated. I has 122 votes, how many are requiered for it to get developed?

+1

+1

+1

+1

+1

While you gather interest, people are moving in github or azure devops.

Disappointing... 

That's a deal breaker for us.

Go and do it now Atlassian. It is critical for large teams and large pull requests.

How else are we supposed to (thoroughly) review a pull request with 50+ files and 5+ reviewers?

And no, it is not always possible to make smaller pull requests, even if that is desirable.

+1 Please consider this feature. GitHub has it since 2019
https://github.blog/2019-07-01-mark-files-as-viewed/

+ 1

+1

+1

+1

This ability in Azure DevOps is a major part of my workflow and it's hard to recommend to our DevOps team that we migrate to Bitbucket without it.

+1

See github implementation -> https://github.blog/2019-07-01-mark-files-as-viewed/

+1

+1

+1

+1

+1

+1

+++1, 

I figured I would would mention BSERV-4266 is very similar. 

We were using SVN/Crucible (Atlassian product) which had this "marked at viewed" feature.  It was essential for keeping my position on reviews containing +50 file changes.

Its sad that their flagship/supported product is missing the features. 

+++1 Please make it happen

+1

+1

+1

+++1

+1   +1

+1

+1

+1 from me. When there are lots of files in a review, being able to mark individual files as "Done" would be great. I really don't mind how simple it is. Just some way to tick things off as I go.

+1

+1 - doesn't need to be complicated. Just mark file as "ok". if it isn't ok, would have a comment. Would help with large PRs submitted, and frankly even short ones!

As the moment, all I can do is comment on files that are fine putting comments like "Looks good". My developers then have to go through each file, looking for actionable comments. Not a good workflow for them or myself. 

It's good to have a flag indicating per-file approved/not approved.  But I would be best to also have a (full! not just the most recent, in case you accidentally toggle the button) history of past approvals and on which commit the approval was given.  Otherwise, the flag becomes nearly useless if the user has to guess/remember what commit they'd approved up to. 

For similar reasons, it will be critical to easily see which approved files in the PR have had subsequent commits without having to click around to find out.

I really wish PRs themselves had this functionality (separate issue).  On long-running issues with many commits and review cycles it gets to be quite challenging to know where you left off last time.  But as long as each approve/unapprove is just another event recorded per file, that may be the most useful anyway.

We are reopening this issue because this is a feature we plan to add in the near future. Stay tuned for updates and thank you for your patience!

Attachment 2013-08-22 10_54_27-e0ibkf5g.png has been added with description: Originally attached to Bitbucket issue #7968 in site/master

Issue BCLOUD-16222 was marked as a duplicate of this issue.

@acoates - That's definitely true in some cases. That said, commit-by-commit review wouldn't be mandatory; you'd be able to see changes across any range of commits in the PR (including the entire range, like what is shown today). This is especially. useful for "show me what's changed since I last reviewed." Either way, we don't plan to add file-level review states (where some files are approved and some aren't) any time soon.

@awbb - Regarding commit-by-commit reviews - in an ideal world, everyone would craft beautiful commits that were logically isolated. But the reality is that commits in a branch often undo things that happened in earlier commits (ie. where the first implementation of an idea didn't quite work out), so reviewing on a commit basis would waste a lot of time.