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
Unknown Object (File)
Wed, Dec 25, 9:14 PM
Unknown Object (File)
Thu, Dec 12, 6:34 AM
Unknown Object (File)
Tue, Dec 10, 6:19 PM
Unknown Object (File)
Nov 27 2024, 9:14 AM
Unknown Object (File)
Nov 25 2024, 8:51 AM
Unknown Object (File)
Nov 21 2024, 3:46 AM
Unknown Object (File)
Nov 17 2024, 9:49 AM
Unknown Object (File)
Oct 27 2024, 4:45 AM
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.