☰

環境間のプロジェクトツリーの共有

tag-icon • tag-icon linux-mint compiling symlink cp hard-link
環境間のプロジェクトツリーの共有

スペースと時間を節約するために、大規模なプロジェクトツリーをネットワークドライブにハードリンクにコピーしました。

cp -a -r --link proj proj_B

（背景：大規模で互換性のない2つの環境で再構築する必要があり、中間および本番の位置決めのサポートが正しく行われていないため、環境「B」で再構築する簡単な方法は次のとおりです。そして、"proj_B/で再構築した後" obj"両方の環境はLinuxMint 16にあります）。

このアプローチの問題は、これらのツリー間で編集内容が（安定して）共有されないことです。たとえば、「proj/foo.cpp」に編集内容を保存すると、新しいinodeを指しますが、「proj_B/foo.cpp」はまだポイントになります。以前のバージョン（おそらく「save temp; mv orig temp2; mv temp orig; rm temp2」の損失回避モード）。

ソースコードを共有するには、ソースディレクトリへのシンボリックリンクが必要だと思います（ただし、バイナリディレクトリを分離する必要があるため、プロジェクトルートへのシンボリックリンクだけでなく）。たとえば、次のようになります。

cp -a -r --symbolic-link proj proj_B

次に、バイナリディレクトリのリンクを解除します（「現在のディレクトリでは相対的なシンボリックリンクのみを生成できます」というメッセージで再帰的なシンボリックリンクのコピーが失敗することを除きますが、「find -exec」を使用して同様の操作を行うか、降伏し、スクリプトを書くことができます）。

でもその前に、完全なのか確認したいです。これを達成するためのより良いツールがあります（例えば、ウォーロックレベルのrsyncフラグの組み合わせなど）。それとも、この共有方法は涙とデータの損失で終わる運命であり、2つのレプリカの使用を単にあきらめる必要があります（2つのレプリカ間で最新の変更をプッシュ/プルすることを忘れたという事実に気付いたら、多くの悪口があります） ？

ベストアンサー1

私はハードリンクを使用しません。一部の編集者はファイルを保存するとハードリンクを切断し、一部はそうではなく、一部は設定できます。ただし、ファイルを保存するときにハードリンクを維持することは、ファイルがその場所に書き込まれることを意味します。つまり、記録中にシステムがクラッシュすると、最終的に不完全なファイルが残ります。これが新しいファイルに保存して所定の位置に移動することが望ましい理由です。ただし、これによりハードリンクが切断されます。

特に、ほとんどのバージョン管理ソフトウェアはハードリンクを壊します。だからハードリンクが消えた。

シンボリックリンクフォレストにはこの問題はありません。編集者がマスターのコピーを指すようにする必要があります。または、編集者がシンボリックリンクをたどっていることを確認する必要があります。

を使用してシンボリックリンクフォレストを作成できますcp -as。ただし、新しいファイルを作成する場合は、対応するcp -asシンボリックリンクを作成するのが不便です（操作は実行されますが、ターゲットがすでに存在するという苦情が表示されます）。単純なシェルループを使用できます。

for env in environement1 environment2 environment3; do
  cd "../$env"
  find ../src \
       -type d -exec mkdir {} + \
       -o -exec sh -c 'ln -s "$@" .' _ {} +
done

おすすめ記事