-
Suggestion
-
Resolution: Unresolved
See example git repository: https://bitbucket.org/pswiecicki/cruc-6806-dup-files-on-review-no-common-ancestry with the following ancestry tree (typical diamond problem):
$ git log --graph --oneline * f5ee7b6 added master * 31b6c4d added master * f90b59e added master * fd84373 Merge branch 'branchRight' |\ | * 16dcba6 added right | * 7f58924 added right | * e04882e added right * | 1efa376 added left 3rd * | 1ee5e72 added left 2nd * | 8c60043 added left 1st |/ * 55b80b9 on master
(each commits modifies single file.txt file)
When creating review for changesets 1ee5e72 (middle commit on branchLeft), 7f58924 (middle commit on branchRight) and f90b59e (merged master) Crucible end up showing two separate files on review, see
This seem to confuse Crucible users, they consider this as a bug, in fact it seems related to CRUC-6568 but it is not.
We could think of a way to improve this. Few options:
- continue to show files separate but make it explicit that they come from different branches
- stop adding same file more than once, find youngest common ancestor and add it to the review (there should always be one for typical repositories with single commit graph). Perhaps also find oldest common descendant and add it too, if there is one. But this brings problem how to show this if there is no common descendant yet. users expects the rightmost version on file revision slider is the most recent version of the file, but there is no really newer/older relation between commits of no common descendant.
- stop adding same file more than once, visualise linear version slider as commit graph? Seems weird and unnecessarily overcomplicated
- is duplicated by
-
CRUC-6844 Adding Git Merge commit will have duplicate files
-
- Closed
-
-
-
- Closed
-
-
- Closed
- is related to
-
-
- Closed
-
- was split from
-
-
- Closed
-
- mentioned in
-
Page Loading...
[CRUC-6806] files from different ancestry lines shown as duplicates
With Git, where branching and merging is very common, listing multiple files makes it very difficult to understand the actual history. For a solution I would recommend that a file is only listed once - and change the slider from a linear list of commits to display the actual DAG (directed acyclic graph) associated with changes to the file. This would make it very obvious to any developer what the most recent version of the file is, show the actual history of changes, and make it easy to compare changes that were made on parallel branches.
If this change were made, it may be worth changing away from a linear slider and instead do a drag and drop where there are "before" and "after" markers that can be dragged and dropped onto different nodes of the DAG.
Also note that the same approach is used for git commits that are rebased out of existence - see CRUC-7913. The summary of this issue talks about "different ancestry lines", but such commits are not part of any "ancestry line" at all. Maybe the summary should be broadened.
The documentation should explain the behavior noted in this issue!
Johan Carlstedt
added a comment - Dear Piotr,
I've attached a screenshot 'old_crucible.png' from the old Crucible version 2.7.10 when used with Fisheye and SVN as the code repository. Here a check-in has been made using the same Jira references across three different code branches 'falcon 10', 'falcon 11' and 'trunk' in SVN.
As can be seen from the screenshot it is clearly identifiable which files have been checked in to which branch without any confusion, with each branch having a separate section in the list of files. The layout in Crucuble version 2.7.10 makes it possible to easily review/verify that the files have been checked in to each branch as expected and allows the reviewer to easily review the files checked in to the different branches to verify that the correct file has been checked in to the correct branch.
When moving to Crucible 3.10.3 with Fisheye and Bitbucket as the code repository we are now seeing the files for each branch listed below each other without any practical way of identifying which version of the file has been checked in to which branch. This is limiting our ability to use Crucible as an effective code review tool when working with more than one branch.
Because this is functionality which used to work well in an old version of Crucible with SVN we believe that the tool has actually regressed in its capabilities in this area when used with Bitbucket and that providing the capabilities that were previously available in the old verion of Crucible to easily identify the branch for each file would be of benefit not only for us but for all Crucible customers/users in general when working on more than one code branch in Bitbucket.
This is an issue which deserves to be prioritised for the next version of Crucible to continue to make Crucible an effective code review tool.
With regards,
Johan Carlstedt
Johan Carlstedt
added a comment - Dear Piotr,
I've attached a screenshot 'old_crucible.png' from the old Crucible version 2.7.10 when used with Fisheye and SVN as the code repository. Here a check-in has been made using the same Jira references across three different code branches 'falcon 10', 'falcon 11' and 'trunk' in SVN.
As can be seen from the screenshot it is clearly identifiable which files have been checked in to which branch without any confusion, with each branch having a separate section in the list of files. The layout in Crucuble version 2.7.10 makes it possible to easily review/verify that the files have been checked in to each branch as expected and allows the reviewer to easily review the files checked in to the different branches to verify that the correct file has been checked in to the correct branch.
When moving to Crucible 3.10.3 with Fisheye and Bitbucket as the code repository we are now seeing the files for each branch listed below each other without any practical way of identifying which version of the file has been checked in to which branch. This is limiting our ability to use Crucible as an effective code review tool when working with more than one branch.
Because this is functionality which used to work well in an old version of Crucible with SVN we believe that the tool has actually regressed in its capabilities in this area when used with Bitbucket and that providing the capabilities that were previously available in the old verion of Crucible to easily identify the branch for each file would be of benefit not only for us but for all Crucible customers/users in general when working on more than one code branch in Bitbucket.
This is an issue which deserves to be prioritised for the next version of Crucible to continue to make Crucible an effective code review tool.
With regards,
Johan Carlstedt Hi config.services@vocalink.com,
Although I agree with you that the current application behaviour might be confusing to some users, this is desired application behaviour to render revisions from other ancestry lines as separate files on review. I hope the issue description explains that sufficiently.
As explained there are few ways we could improve this behaviour, each of them have some pros and cons. Not sure what you would expect Crucible to do in such circumstances, I can only guess you would prefer a single file with all revisions (whether they belong to a single line of ancestry or not) to be rendered in the revision slider. In my opinion this will still confuse some users, they expect changes on the slider to be listed in the hierarchical order (ancestors to the left), while with parallel ancestry lines it's impossible to determine such relation. Also, setting up a slider where "from revision" is set on one ancestry line and "to revision" is set on another ancestry line would show a diff that most likely would be meaningless.
Feel free to leave a comment how would you like this feature to work, explain your scenarios so we fully understand it. According to https://confluence.atlassian.com/support/implementation-of-new-features-policy-201294576.html we take several factors into account (e.g. number of votes) when prioritising issues to ensure we focus our efforts on the items most beneficial to our users. For now I can't provide any ETA as we don't have plans at the moment to address this issue.
Piotr Święcicki,
FishEye/Crucible Development Manager
Config Services
added a comment - Hello,
Please can you provide an update on this issue? Any ETA?
Many thanks.
Nick
Config Services
added a comment - Hello,
Please can you provide an update on this issue? Any ETA?
Many thanks.
Nick 
Nitin Gupta
added a comment - Hi, Has there been any update on this defect ...This makes it difficult for projects having multiple branches in development and lots of manual merging happening between branches .
Reviewers do need to confirm if the changes are merged in the correct branches , but Crucible just doesn't let you know which branch the file is belonging to .
Nitin Gupta
added a comment - Hi, Has there been any update on this defect ...This makes it difficult for projects having multiple branches in development and lots of manual merging happening between branches .
Reviewers do need to confirm if the changes are merged in the correct branches , but Crucible just doesn't let you know which branch the file is belonging to .
Hi everyone,
We have recently reviewed this issue and the overall interest in the problem. As the issue hasn't collect votes, watchers, comments, or support cases from many customers during its lifetime, it's very low on our priority list, and will not be fixed in the foreseeable future. That's why we've decided to resolve it as Not Being Considered.
Although we're aware the issue is still important to those of you who were involved in the conversations around it, we want to be clear in managing your expectations. The Fisheye&Crucible team is focusing on issues that have broad impact and high value, reflected by the number of comments, votes, support cases, and customers interested. Please consult the Implementation of New Features Policy for more details.
We understand how disappointing this decision may be, but we hope you'll appreciate our transparent approach and communication. Atlassian will continue to watch this issue for further updates, so please feel free to share your thoughts in the comments.
Kind regards
Marek Parfianowicz
Development Team Lead