Page MenuHomePhabricator

"Open Revisions Affecting These Files" should weight severity of changes
Closed, WontfixPublic


The section 'Open Revisions Affecting These Files' can be daunting and skipped over if there is a lot of noise. One means of possibly dealing with this is weighting the severity of the possible overlapping diffs. Some things to consider:

  • @generated files.
  • Changes with multiple file overlaps
  • Changes moving files being editing
  • ???

Event Timeline

joshuaspence raised the priority of this task from to Needs Triage.
joshuaspence updated the task description. (Show Details)
joshuaspence added a project: Differential.
joshuaspence added a subscriber: joshuaspence.

What problem are you running into?

It's important for us to understand the core problem, as well as separate out Phabricator development from 'real development'.

If these are false positives that disrupt your workflow, I want to know what that workflow is. There may be other tasks or solutions that are better suited and solve more problems.

The main issue as I see it is "Open Revisions..." are useless, at least on this install, and possibly many others. T5658 covers perhaps a better query, and maybe a better fix is to have some sort of "severity" of overlap indicated instead. Generated files would be very low, but multiple files might be very high.

chad renamed this task from "Open Revisions Affecting These Files" should ignore generated files to "Open Revisions Affecting These Files" should weight severity of changes.Jan 20 2015, 3:36 AM
chad triaged this task as Wishlist priority.
chad updated the task description. (Show Details)

@generated files.

We can plausibly ignore generated files, although this is complex and expensive because detecting that a file is generated depends on configuration, event hooks, examining the file content, examining diff properties, and possibly fishing around in repositories.

Changes with multiple file overlaps

We can plausibly do this, but I don't think there's any reason to believe that this is a good rule. In particular, I worry that this will create a lot of false negatives, because editing a single file can be important.

Changes moving files being editing

This is expensive to compute and complex to implement (we need to load all candidate revisions, load their changesets, and then compare them). This doesn't seem too important to me.


  • I don't think this panel is very useful in general and would support removing it or burying it.
    • However, I have some anecdotal evidence that other users do find it much more useful than I do.
  • Ignoring @generated files is reasonable but should wait for T784.
  • T5658 has a patch to prune old/crufty revisions from this view.
  • Other types of magic don't seem worth the performance cost and/or implementation complexity to me.

Just to let you know, I used this panel to find out all of the revisions that were affecting individual Drydock files so that I could merge down changes correctly.

epriestley claimed this task.

We made this a little smarter and a little less prominent (on a non-default tab) and I feel like it's generally in a more reasonable place now. I don't currently expect to make it significantly more complex, and none of the rules proposed here feel like simple, unambiguous improvements to me.