0

私が働いている場所には、非常に大きなリポジトリがいくつかあります。Subversion のスパース ディレクトリ機能を大いに活用しています。ただし、リポジトリの空の（またはまばらな）チェックアウトを実行してから、長いパスのディレクトリを再帰的にすべて一度に「追加」できないように見える理由について、私は途方に暮れています。次のレイアウトの「project1」というリポジトリがあるとします。

foo/
bar/
  baz/
  brak/
  schwing/yadda/etc/i386/package/

(これは単なる例です。実際のリポジトリはかなり複雑です。) 「foo」や「bar/ baz」全体。だから今、私はこのようなことをします：

svn checkout --depth=empty svn+ssh://svn/project1 project1
cd project1
svn update --depth=empty bar
svn update --depth=empty bar/baz
svn update --depth=empty bar/baz/schwing
svn update --depth=empty bar/baz/schwing/yadda
svn update --depth=empty bar/baz/schwing/yadda/etc
svn update --depth=empty bar/baz/schwing/yadda/etc/i386
svn update --depth=infinity bar/baz/schwing/yadda/etc/i386/package

私は密集していますか、それともこれを行うより短い方法はありませんか? 私はSVNのドキュメントをチェックし、それをグーグルで検索しました。私がやりたいことは次のようなものです：

svn checkout --depth=empty svn+ssh://svn/project1 project1
svn update --depth=infinity bar/baz/schwing/yadda/etc/i386/package

「package」のすべての親がファイルシステムに自動的に追加されますが（「mkdir -p」と同様）、パスで指定された子以外は何も入力されません。上記のコマンドを試してみると、SVN はエラーを出さず、パスが「スキップされた」と表示され、作業ディレクトリを調べても何も起こらなかったことがわかります。

これに対処するシェル関数を作成できることはわかっていますが (おそらくそうするでしょう)、もっと良い方法があるはずだと感じています。ご協力いただきありがとうございます。

4

2 に答える 2

1

Subversion は、CVS のワークフローと互換性があり、できるだけシンプルで使いやすいように設計されています。まばらなチェックアウトは実際には必要性の高い項目ではないため、この機能は実際には取り組まれていませんでした。プロジェクトの 95% で、開発者は特定のディレクトリをチェックアウトしたいと考えています。

しかし、あなたがしていることを見て、単純にこれをやらないのはなぜですか?

$ svn co svn+ssh://svn/project1/bar/baz/schwing/yadda/etc/i386/package project1-package

.profile次のように、または.bashrcファイルに URL 環境変数を設定することもできます。

PACKAGE_URL=bar/baz/schwing/yadda/etc/i386/package

そして、次のように使用します。

$ svn co $svn+ssh://svn/project1/$PACKAGE_URL project1-package

そうすれば、作業中のディレクトリをチェックアウトするだけです。

ところで、Subversion よりもまばらなチェックアウトをうまく処理するバージョン管理システムがあります。たとえば、Perforce はそれが得意です。

もちろん、パワーがあるとシンプルさが失われます。Perforce からチェックアウトするには、チェックアウト対象をどのディレクトリにマップするかを示すビューを作成する必要があります。Perforce のマッピングを使用すると、あらゆる種類の凝った作業を行うことができますが、ほとんどの開発者は、複雑さから得られる苦痛は、簡単にあきらめる価値がないことに気付きます。

応答

質問で述べたように、リポジトリのレイアウトを多かれ少なかれ反映するために、作業ディレクトリのレイアウトが必要です。(ほとんどの場合、自動化されたツールの利点のためです。) レポ内の任意のパスで自分の作業ディレクトリを開始できることは承知しています。VCS を切り替えることは選択肢ではありません。私が働いている会社は、バックエンドで Subversion (おそらく特定のバージョンでさえ) と永久に結婚しています。ただし、提案に感謝します。– エイル

比較のためにPerforceについて言及しました。VCS を意のままに切り替えることはできないことは理解していますが、Subversion は本当にあなたが望んでいることを実行しません。これは主に Subversion の初期設計によるものです。

Subversion は、使いやすく、CVS ワークフローに従うように設計されています。CVS は最も人気のあるバージョン管理システムであり、その設計もシンプルでした。主にその点を強調するために、Perforce について少し触れました。Perforce は、あなたが求めていることを大胆に行うことができますが、余分な複雑さを犠牲にして、Perforce を多くの開発者が嫌うものにしています。

これはビルドツールを模倣することに関係があるとあなたは言いましたが、それが何を意味するのかわかりません。

ビルドツールは、チェックアウトディレクトリのスーパーディレクトリであるディレクトリに物を置きますか? これは、通常、ビルド ツールが行うには悪いことです。ビルドはユーザーのファイルやディレクトリに望ましくない影響を与える可能性があるため、有効性が制限され、副作用が生じる可能性があります。これを行わないようにビルドを変更できますか?

おそらくこれを行うと、バイナリをビルドツリーの他の場所にチェックインして、他のビルドが使用できるようになります。Jenkinsなどのビルド ツールには、あるビルド ジョブから別のビルド ジョブにアーティファクトをコピーする機能があります。これにより、最初にビルド ツールにチェックインおよびチェックアウトすることなく、ビルド アーティファクトを共有できます。それはあなたの問題を解決しますか？

アーティファクト リポジトリを作成することもできます。Java の世界では、Ivy 拡張機能を備えた Maven と Ant の両方がこれを非常にうまく行っています。一般的に使用されるサード パーティの Java アーティファクト用の世界規模のレポジトリ ネットワークさえあり、ビルド環境に厳密にローカルなものを簡単に追加できます。

非 Java の世界でこれを行うことは、非 Java の世界で同じ Java ツールを使用して行うのはそれほど難しくありません。Artifactoryなどのツールを使用してC++ 共有オブジェクト ライブラリを格納している場所をいくつか見てきました。標準の Make ファイルは、curlまたはwgetビルド時に必要なアーティファクトを取得できます。ほとんどのビルド ツールでは、ビルドされたアーティファクトを Artifactory に問題なく送信できます。

package2たぶん、遅かれ早かれ の兄弟ディレクトリが必要になるでしょうpackage。元のスキームでは、単一のディレクトリに移動してからsvn update --set-depth=infinity package2.

個別のチェックアウトで同様のことができます。

 $ svn co svn+ssh://svn/project1/bar/baz/schwing/yadda/etc/i386/package project1/bar/baz/schwing/yadda/etc/i386/package 
 $ cd ..
 $ svn co svn+ssh://svn/project1/bar/baz/schwing/yadda/etc/i386/package2 package2

ここで、リポジトリ構造を模倣しますが、深いスパース チェックアウトですべての作業を行う必要はありません。

上記のいずれも役に立たない場合は、スパース チェックアウトを実行するスクリプトを作成する以外にできることはあまりありません。URL を受け取り、それを解析して一連のまばらなチェックアウトに変換するスクリプトを作成することもできますが、標準の Subversion コマンド ライン クライアントに組み込まれているようなものはありません。

于 2012-05-21T22:52:30.153 に答える