Page MenuHomePhabricator

Update the "WorkingCopy" API and create a fallback "Filesystem" working copy
ClosedPublic

Authored by epriestley on Apr 8 2020, 3:35 PM.
Tags
None
Referenced Files
F15564547: D21070.id50199.diff
Wed, Apr 30, 12:47 PM
F15558581: D21070.id50195.diff
Tue, Apr 29, 4:00 AM
F15551341: D21070.diff
Sun, Apr 27, 4:28 PM
F15547000: D21070.id50199.diff
Sat, Apr 26, 5:44 PM
F15541952: D21070.id.diff
Fri, Apr 25, 2:36 PM
F15539239: D21070.id50199.diff
Fri, Apr 25, 12:15 AM
F15531826: D21070.diff
Wed, Apr 23, 1:14 PM
F15512187: D21070.id50199.diff
Thu, Apr 17, 8:37 AM
Subscribers
None

Details

Summary

Ref T11968.

  • Allow "WorkingCopy" objects to maintain an API object and update callers ("get...()" instead of "new...()").
  • Always generate a WorkingCopy object and a RepositoryAPI object.

Currently, code has to look like this:

$working_copy = ...
if ($working_copy) {
  $repository_api = ...
  if ($repository_api [instanceof ... ]) {

This is clunky. There's also no reason some "arc" commands can't run outside a VCS working directory without special-casing how they interact with the filesystem.

Conceptually, model the filesystem as a trivial VCS (which stores exactly one commit, always amends onto it, and discards history). Provide a trivial WorkingCopy and API for it.

(This change isn't terribly interesting on its own, but chips away at landing the new Hardpoint infrastructure.)

Test Plan

Ran arc version, arc upgrade.

Diff Detail

Repository
rARC Arcanist
Lint
Lint Not Applicable
Unit
Tests Not Applicable