Page MenuHomePhabricator

[Wilds] Refine the working copy selection algorithm for Subversion vs Git/Mercurial
ClosedPublic

Authored by epriestley on Sep 25 2018, 10:32 PM.
Tags
None
Referenced Files
F14074027: D19707.diff
Thu, Nov 21, 3:46 AM
Unknown Object (File)
Sun, Nov 17, 9:49 AM
Unknown Object (File)
Sun, Oct 27, 4:45 AM
Unknown Object (File)
Wed, Oct 23, 6:52 AM
Unknown Object (File)
Oct 21 2024, 6:30 PM
Unknown Object (File)
Oct 20 2024, 5:52 PM
Unknown Object (File)
Oct 9 2024, 10:15 AM
Unknown Object (File)
Sep 6 2024, 10:29 PM
Subscribers
None

Details

Summary

Ref T13098. I didn't fully capture all the nuances of the old algorithm, and the behavior we want is slightly more complicated. This adjust things to try to express the more complicated behavior in a relatively clear (?) way.

When a bunch of working copies are nested inside one another, first pick the deepest one, then ask it to pick the best option among all working copies of the same type.

For Git and Mercurial repositories, just pick the deepest one.

For Subversion repositories, pick the directory with .arcconfig if one exists, or the shallowest directory otherwise (this could be more sophisticated, some day).

The general idea here is that if /a is a Git repository and /a/b/c is a Git repository and you run inside /a/b/c, that should be the working copy.

But we have to use a different rule for Subversion because every directory had a .svn directory in it until SVN 1.7.

Test Plan

Locally, with core/lib/arcanist/, got arc to anchor to arcanist/ instead of core/ with the new ruleset.

(This will eventually get more extensive Subversion testing.)

Diff Detail

Repository
rARC Arcanist
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

epriestley created this revision.
This revision is now accepted and ready to land.Sep 26 2018, 6:04 PM
This revision was automatically updated to reflect the committed changes.