Relocated files aren't treated as newly created files by the worker. This
can lead to the worker trying to look up information about deleted files
in the wrong location.
Details
Details
- Reviewers
epriestley - Group Reviewers
Blessed Reviewers - Maniphest Tasks
- T4030: Phabricator can't process commits which delete files from a relocated directory
- Commits
- Restricted Diffusion Commit
rP62edbb8e21f3: Treat relocated files as added files in svn worker.
See T4030
Diff Detail
Diff Detail
- Branch
- master
- Lint
Lint Passed - Unit
No Test Coverage
Event Timeline
Comment Actions
Hmm thinking about it, this is no good.
If instead of deleting a file added by the relocation, the relocation deleted a file that was previously there, I think we would see a similar log entry in svn but this time we'd be looking for the file in the wrong place (after this patch). We probably can't treat relocations as simple adds and will need to add specific logic for that operation.
Comment Actions
Actually just checked that by rearranging the commits in the first example. You can see the output here:
$ svn log -c 11 https://subversion.assembla.com/svn/phabricator-example -v ------------------------------------------------------------------------ r11 | deanreilly | 2013-10-27 21:04:56 +0000 (Sun, 27 Oct 2013) | 1 line Changed paths: M /branches/second-branch R /branches/second-branch/foo (from /trunk/foo:2) Merged commits 3 and 2. ------------------------------------------------------------------------
SVN doesn't mark the files in this scenario so the change as proposed should be fine.
Comment Actions
I think "R" is "Replace", not "Relocate", and we only get it when something is deleted and something else is moved on top of it (here, implicitly by a merge, I guess? Although I didn't have much luck building a simpler synthetic commit without the merge), so this patch should be correct in all cases, I believe. Some notes in T4030. Thanks for tracking this down!