Page MenuHomePhabricator

Some workflows of arc are broken on Windows
Closed, DuplicatePublic

Description

EXCEPTION: The current working directory is not part of a working copy for a supported version control system(Git, Subversion or Mercurial). at [<arcanist>\src\repository\api\ArcanistRepositoryAPI.php:85]
arcanist(head=stable, ref.master=7d15b85a1bc0, ref.stable=7b0aac5c6f31), phutil(head=stable, ref.master=92882eb9404d, re
f.stable=52748950bb36)
  #0 ArcanistRepositoryAPI::newAPIFromConfigurationManager(ArcanistConfigurationManager) called at [<arcanist>\src\workflow\ArcanistVersionWorkflow.php:48]
  #1 ArcanistVersionWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394]

This occurs on Windows 7 running php5 or php7 and is reliably repeatable on many clients. It does not occur on linux clients.
arcanist and php installed on C:\Program Files (x86)\arcanist\arcanist\ Git repo either on drive D: or drive C: makes no difference.

Analysis of the issue is that the failure is a consequence of calling newFromPathWithConfig() with path set to C:\Program Files (x86)\arcanist\arcanist
This calls walkToRoot() with the default root parameter '/'
This function calls resolvePath() (which btw erroneously under windows does not think / is an absolute path!) and subsequently concludes in any case that the "root" is not / but the git repo root.
The net result is that the FileList::contains() tries to compare these disconnected paths and returns false which then returns an empty array of possible locations for .arcconfig to exist in. This prevents newFromPathWithConfig() from successfully finding .arcconfig (in the arcanist install directory) even though it is present.

I dont know enough about the wider use of these lower level functions to know how to fix it reliably but replacing '/' with 'C:\' in walToRoot() as T8821 suggested as a "Shameful fix" does not fix the problem but at least gets you a little further but then subsequently exhibits the failure described earlier in that task and in T8291 with the an instance of bad git log -1 --format=" H ct" command parameters.

Event Timeline

chad renamed this task from Executing "arc version" on Windows results in EXCEPTION: (Exception) The current working directory is not part of a working copy for a supported version control system.... to EXCEPTION: The current working directory is not part of a working copy for a supported version control system.Jun 15 2016, 8:52 PM
chad added projects: Windows, Arcanist.
chad updated the task description. (Show Details)

As someone who regularly uses Arcanist on Windows, I can't say I've seen this issue. You should try placing Arcanist in a writable directory, like C:\Tools\Arcanist. Installing it into "Program Files" is probably not ideal, as that's not a writable location.

We have a large user base using various install locations on their PC's. The issue has come about following a recent upgrade from a 2015 version with more than one person affected.
If you look at the code I cant see why you would need write access - it is just processing path strings.
Anyway I have moved the install to your suggested directory but with no change to the fault symptom.

We're basically having lots of problems with Windows; There are a few reports about arc version just not working on Windows (I'm a little surprised @hach-que doesn't run into this; Can you maybe do a quick phriction page about your Windows setup, as in "this setup works, do this"?).

Part of the issue is that there's so many ways to use arc under Windows (cmd, powershell, cygwin, git-bash...), and each of them act differently when it comes to filesystem access and shell escaping.

avivey renamed this task from EXCEPTION: The current working directory is not part of a working copy for a supported version control system to Some workflows of arc are broken on Windows.Jun 16 2016, 8:20 PM
avivey updated the task description. (Show Details)

I saw the issues about windows being generally broken. I sympathize with the team's plight having been there too many times with cygwin and git bash over the years. FWIW I think the best approach is to normalize the path references back to unix format as fast as possible. The approach of mapping driver letters C:\ D:\ to /c and /d etc is reasonable. Beyond that there is the usual handling of spaces and () {} etc to consider where php/bash might get confused.

Beware of Windows capitalization insensitivity too. This can catch you out in a variety of ways especially if you call underlying methods to determine the existence of paths or files.

Whilst it would be good to capture all use cases I would personally suggest concentrating on git bash (msysgit) as likely to cover the majority of users (or at least give people a route to the solution) given that its a UI-centric activity. There cannot be very many people using PowerShell directly and DOS, whilst common, is arcane and should be deprecated. For example all our phabricator users either use git bash (or some scripts whith Git Extensions that do the same thing) to drive diffusion for arcanist. Using git bash also allows nice things like bash aliases to be set for option switch defaults.

Ultimately the issue might go away as Microsoft appear to be moving towards supporting bash directly but it will be a while before the install based all move to a version of Windows that might permit this.

Regarding the specific fault it would be interesting to know why arc expects to be within a repository (either for the user repo or for arcanist) in the first place just to print out a version string. Surely if php can execute arc script that should be sufficient?

Regarding the specific fault it would be interesting to know why arc expects to be within a repository (either for the user repo or for arcanist) in the first place just to print out a version string. Surely if php can execute arc script that should be sufficient?

It's cd-ing to the arc install directory and does git log to read the version information.