Vagrant + 作業フォルダの共有で発生するトラブルについて
Vagrantに限らず、仮想マシンを使ったあらゆる環境で起こりうる話です。 まず私の環境ですが、こんな感じです。
最初の記事でも説明してあります。
この構成の特徴としては、Ubuntu上の/shareと言うディレクトリをsambaで公開し、Windows上からネットワークフォルダとしてアクセスする点です。
主にWindows上にインストールされているエディタ類がこのディレクトリにアクセスします。一方、MyDocumentsも作業フォルダとして使っています。
ちなみにMyDocumentsにデータを入れるとWindowsが重くなると前から言われてきましたが、これは今もそうなんでしょうか。 よくわかりませんが、あまりいろいろ考えるのも面倒なので私は大人しくMy Documentsをデータフォルダとして使っています。
この構成の問題点
図をみればわかりますが、GitHubとnode.jsがWindowsとUbuntuどちらにも存在しています。
仮想マシンのホストとゲスト両方に同じミドルウェアが入っていたりすると、何かでトラブルになるのは目に見えているわけで、実際トラブルになりました。
まず、node.jsについて。
職場でWindowsを使い始めて間もない頃は、私も未熟でしたので、例えば/shareのフォルダ内のプロジェクトに対してwindows上からnpmを走らせたり、Ubuntu上からnpmを走らせたりしてました。
WindowsとUbuntuではnodeのバージョンも違うし、まあ当然動かなくなります。細かい原因がどうとかいうのは置いておいて、こういうことはやめておいたほうがいいと本能で感じ取ることができる程度の感覚は欲しいものです。私がバカでした。
次にGitHubについて。これがいろいろと厄介なのです。
- filename too long の問題
Windowsでは260文字以上のパスが扱えないという問題があります。
こちらに詳しく載っていました。
というわけで、フォルダ構造の深いプロジェクトなどがあると、gitはfilename too longとエラーを吐き出してチェックアウトを中断してしまいます。
この問題が起きる場合、シェルでgit config –system core.longpaths trueと打てばチェックアウトできるようになります。
VSCodeはGitと連携できますが、連携すると開いたフォルダに.gitがないか探しに行きます。
Ubuntu上のプロジェクトを読んだ場合も例外ではなく、.git以下を検出して読みに行ってしまうのですが、 その際パフォーマンスが急激に低下します。
何故かというと、Windows版のgitがwindowsとは違うファイルシステム上にあるレポジトリを読みに行っている関係で、 ファイルシステムの違いによるパーミッションやファイル終端の処理の違いを検出してしまい、結果としてプロジェクト内のすべてのファイルに差分があるものとみなされてしまうからだと思われます。
gitはせっせと全ファイル分の差分リストを作っているわけでただでさえ時間がかかるのですが、さらに差分データベースへの登録がうまくいっていないのか、どうも処理に無限ループが起きているようです。
そういうわけで、レポジトリの読み込みはいつまでたっても終わらず、PCのファンが激しく回り始めてだんだん筐体が熱くなっていきます。
まとめると、以下のケースでvscodeをgitと連携させるのは地雷です。
・Windows上から、VmwareやVirtualbox等でLinuxなどを起動している
・プロジェクトは仮想マシン上にあり、sambaなどでWindows側からアクセスできるようにしている
仮想マシン上にあるものは仮想マシン上のgitで管理するべきのは当然なのですが、vscodeなどエディタをgitと連携させていると、samba上のレポジトリを開いた時点でこのトラブルが発生します。
vscodeで仮想マシンのファイルを触る場合、git連携を諦めるしかないのが現状のようです。
どうしてもgit連携したい場合はホストマシンの時とゲストマシンの時でエディタを使い分けるといった解決法になります。 結局のところ、開発環境というものはOSの垣根を越えないシンプルな構成が望ましいということです。
私がMacを使えば全て解決するのですが・・・
