Page MenuHomePhabricator

Handle folder copies/moves more gracefully
Closed, WontfixPublic

Description

With svn, copying folders is a common operation for branching, tagging, etc. Diffusion currently shows a line item for each subfolder and file within the directory.

There are two main issues with this:

  1. It makes it very easy to hit the 1000 file limit for diffusion to consider it an "Enormous Commit" where it will refuse to show anything. There is no way to coerce it to show more.
  2. It also obscures the actual intent of the commit (say copying trunk to a branch), instead requiring somebody to look through the line items for each one and see that it was just a plain copy

A folder move doubles the count (and exacerbates this issue).

Suggestions for possible improvement:

  • Add a button to allow users to override the enormous file block.
  • If the svn operation is just a plain copy or move, show it as such. I think this most ideally models the way svn uses these operations. (i.e. just show /project/tag/20150305 as new instead of every subfile as well).

Tangentially related to T7467.

Event Timeline

sshannin raised the priority of this task from to Needs Triage.
sshannin updated the task description. (Show Details)
sshannin updated the task description. (Show Details)
sshannin added a subscriber: sshannin.
chad renamed this task from Handle folder copies/moves more gracefully. to Handle folder copies/moves more gracefully.Mar 5 2015, 11:10 PM
epriestley claimed this task.
epriestley added a subscriber: epriestley.

I'm not aware of any current customer interest in improving this behavior, and it's likely a lot of work to improve what is largely a moot case (there's usually no value in reviewing individual file-level changes in a "create a new branch X" commit) that only affects Subversion.

Add a button to allow users to override the enormous file block.

See also T8612. I invite anyone requesting that I remove a limit and just show everything on a page to provide an example program which they believe generates a useful webpage for an arbitrarily large input, thus demonstrating that the limit is unnecessary. I suspect that in all cases, I can easily construct an input which is actually too large for the program to produce a useful page from.

(there's usually no value in reviewing individual file-level changes in a "create a new branch X" commit)

Completely agree that there's no value in reviewing those individually. But to be clear, my point in making this ticket was mostly that you can't discern from the browser that this was a "create a new branch" commit. Right now it just renders the whole file tree saying showing 3000 files individually copied instead of a simpler/single line saying the whole directory was copied.

I'm not aware of any current customer interest in improving this behavior, and it's likely a lot of work to improve what is largely a moot case

Understood. I agree it is low impact (I just jump to native SVN to grok what the change actually is).