Uploaded image for project: 'Crucible'
  1. Crucible
  2. CRUC-6806

files from different ancestry lines shown as duplicates

XMLWordPrintable

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      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

        1. httpsid.atlassian.comverify-emailapplication=jac&email=johan.carlstedt%40vocalink.com&tenant=&token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2ZXJpZmljYXRpb25UeXBlIjoidmVyaWZ5Iiwic2NvcGUiOiJlbWFpbFZhbGlkYXRpb24iLCJyZW1lbWJlck1lIjoiZmFsc2UiLCJwcm9tcH.png
          httpsid.atlassian.comverify-emailapplication=jac&email=johan.carlstedt%40vocalink.com&tenant=&token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2ZXJpZmljYXRpb25UeXBlIjoidmVyaWZ5Iiwic2NvcGUiOiJlbWFpbFZhbGlkYXRpb24iLCJyZW1lbWJlck1lIjoiZmFsc2UiLCJwcm9tcH.png
          233 kB
        2. old_crucible.png
          old_crucible.png
          233 kB

            [CRUC-6806] files from different ancestry lines shown as duplicates

            Marek Parfianowicz made changes -
            Fix Version/s New: N/A [ 54415 ]
            Marek Parfianowicz made changes -
            Status Original: Gathering Interest [ 11772 ] New: Not Being Considered [ 11776 ]

            Marek Parfianowicz added a comment -
            Atlassian Update – 31 January 2020

            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

            Marek Parfianowicz added a comment - Atlassian Update – 31 January 2020 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
            Marek Parfianowicz made changes -
            Labels New: jac-cleanup-phase7
            Katherine Yabut made changes -
            Workflow Original: JAC Suggestion Workflow [ 3020340 ] New: JAC Suggestion Workflow 3 [ 3635311 ]

            Peter Solfest added a comment - - edited

            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.

            Peter Solfest added a comment - - edited 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.
            Marek Parfianowicz made changes -
            Component/s New: Code reviews [ 54890 ]
            Owen made changes -
            Workflow Original: Confluence Workflow - Public Facing v4 [ 2946938 ] New: JAC Suggestion Workflow [ 3020340 ]
            Owen made changes -
            Workflow Original: FECRU Development Workflow - Triage [ 939182 ] New: Confluence Workflow - Public Facing v4 [ 2946938 ]
            Status Original: Open [ 1 ] New: Gathering Interest [ 11772 ]
            Owen made changes -
            Issue Type Original: Improvement [ 4 ] New: Suggestion [ 10000 ]

              Unassigned Unassigned
              pswiecicki Piotr Swiecicki
              Votes:
              8 Vote for this issue
              Watchers:
              12 Start watching this issue

                Created:
                Updated: