問題タブ [externals]

このページに出くわしていなければ、svn:externals を知ることはできません。そこで、作業フォルダーをセットアップします。それで

"svn update" は symfony フォルダー全体を登録し、かなり遅いです。私はそれが一度の痛みだと思った。ただし、「svn up」と入力するたびに、SVN は外部リポジトリをチェックします。「svn update」を十分に速くするには、 --ignore-externals を使用する必要があります。

svn:externals が非常に遅い場合、どのような利点があるのか​​ 疑問に思っています。symfony を自分のリポジトリにコピーしたほうが確実に高速なソリューションです。

「メイン」リポジトリにいくつかの外部gitリポジトリを含めるには、いくつかのオプションがあります。

• サブモジュール
• ブレード
• サブツリー

最初のものは基本的に誰もが反対するようにアドバイスされているようです。2番目と3番目は、サブツリーパターンの実装だと思います。

1つは良いですか？どちらを使うべきですか？なんで？どうすればそれらから選択できますか？

外部リポジトリを現在の作業コピーにチェックアウトしようとしています。これは私のセットアップです: 現在の作業コピー

D:\working_copy\

外部パス

D:\external_working_copy\uploads

次に、svn:external プロパティを D:\working_copy\ に設定します。

ファイルをアップロードします:///D:/SVN/external_working_copy/trunk/uploads

次に、D:\working_copy\ で update を実行すると、次の結果が得られました。

D:\working_copy\uploads

しかし、file:///D:/SVN/external_working_copy/trunk/uploads のコンテンツを D:\working_copy\ のルートに移動し、D:\working_copy 内にアップロードを作成しないようにします。

として設定しようとしました

/ file:///D:/SVN/external_working_copy/trunk/uploads

しかし、私が得たものはすべて:

'D:\working_copy' の無効な svn:externals プロパティ: ターゲット '/' は絶対パスであるか、'..' を含みます

前もって感謝します

そのため、私はTCLプログラミングの方法に非常に慣れておらず、経験がありません。最初に出力ファイルを削除して、他の誰かが作成したプロシージャを呼び出すスクリプトを作成しました。次に、私が書いた追加のロジックを実行します。

ロジックを 2 番目の proc に移動すると、すぐにそのロジックの一部 (つまり rm コマンド) が壊れました。

私が知る限り、中央実行内の行の最初のプログラム (proc 定義に続くテキスト) は、「exec」コマンドなしで正常に実行されます。ただし、proc 内に移動する場合は、「exec」コマンドが必要になります。

TCLがこのように動作する理由を誰かに説明できますか?

例えば

..

..

..

*この奇妙な動作は、スクリプトを vmd にフィードしているプログラムに固有のものである可能性があることに注意してください。これには、独自の TCL 動作が組み込まれています。おそらく、あなたの回答で、これが他の通訳者にとっても標準であるかどうかを示すことができますか?

を実行するsvn updateと、ですべての明示的なリビジョンを指定したにもかかわらず、すべての外部がリロードsvn:externalsされ、このプロパティまたは問題のファイルは変更されていません。

これを防ぐ方法はありますか？

同じSubversionリポジトリに2つのプロジェクトがあります。どちらも、さまざまな目的でいくつかの標準コード/クラス（Zend / PEAR / phpMyAdminなど）を使用しています。リポジトリは次のように構成されています。

• \shared\trunk-両方のプロジェクトで使用されているもの
• \main\project1\trunk\sharedsvn：external of\shared\trunk
• \main\project2\trunk\sharedsvn：external of\shared\trunk

これは、1つの場所で共通コードを更新するだけでよいという点でうまく機能します。また、ローカル、デモ、本番環境の両方で機能すると確信しています。

ただし、TortoiseSVNは、常に3つのディレクトリすべてをチェックアウトするのに時間がかかるようです。そして今、私はいくつかのタグとブランチを持っているので、それはさらに遅くなります。クラスフォルダは、約3500のファイルと1500のフォルダで構成されています。

何をすべきか？標準クラスのバージョン管理を維持することは良い習慣ですか？

考えられる代替案：外観を削除し、代わりにPhingにクラスフォルダーのエクスポートを処理させますか？

現在、SVN を使用して jboss サーバー構成を管理しています。各作業コピーに同じサブディレクトリの複数のコピーが必要ですが、サーバー上の同じディレクトリを参照して、ファイルを変更するとすべてのコピーが更新されるようにします。

例：

• /server/bin (共有)
• /server/node-01 (リポジトリ /server/node のコピー)
• /server/node-02 (リポジトリ /server/node のコピー)

gitを使用して同じことを達成することは可能ですか? （多くの）同様の質問で決定的な答えを見つけることができませんでした。

複数のプロジェクトがあり、それぞれが同じライブラリ プロジェクトを参照しています。すべてのプロジェクトで同じ変更をサポートすることなく、これらのプロジェクトの 1 つをサポートするためにライブラリを変更できるようにしたいと考えています。SVN では、ライブラリの特定のリビジョンをチェックアウトする外部を設定するだけで、チェックアウトしたライブラリのリビジョンを明示的に変更することを決定しない限り、そのリビジョン以降の変更は取り込まれませんでした。外部の概念が TFS で明示的にサポートされていないことは他の投稿から理解していますが、Bart Wullems は彼のブログに、Project Linker (http://bartwullems.blogspot.com/2010) を使用してこの動作をシミュレートできる可能性があることを示唆する何かを投稿しました。 /08/simulating-svn-externals-feature-in-tfs.html)。

TFS を使用するときに svn:externals のこの側面をシミュレートする良い方法を知っている人はいますか?

ありがとう。

別の Subversion リポジトリに保持したい Zend_Framework アプリケーションがいくつかあります。ただし、これらのアプリケーションは、同じデータベース抽象化レイヤーと、同じ共通コンポーネントのいくつかを共有しています。

何とかアプリ間で共通点を共有したいと考えています。私たちが持っている現在のアイデアは次のようになります

ここで、itg-app リポジトリに itg-common リポジトリへの外部参照を持たせたいと考えています。問題は、たとえばitg-app/trunk/commonにリンクしたいitg-common/trunk、itg-app/branches/foo/commonにリンクしたいitg-common/branches/fooなどです。つまり、一般的なパターンはitg-app/$BRANCH/common -> itg-common/$BRANCHです。

原則として、これらの外部オブジェクトを作成できますが、マージしようとすると常に問題が発生します。$/trunkたとえば、 からへのマージは、を指すようにするプロパティを$/branches/production上書きします。svn:externals$/branches/production/commonitg-common/trunk

これは理にかなっていますか？もしそうなら、この問題を回避する方法はありますか？そうでない場合、その理由は何ですか?代わりに何をすべきでしょうか?

別のプロジェクトのソースを含める必要があるプロジェクトがいくつかあります。すべてのプロジェクトは、リビジョン コントロール ソフトウェアによって管理されます。実際、それらは今のところ同じローカルの bazaar リポジトリの一部です。望ましいレイアウトは次のようになります。

そのようなツールに関する私の経験は不足しています。私の最初のアイデアは、 のOtherProjectサブフォルダーMainProjectsが何らかの形で bzr 外部ファイルを使用して他のプロジェクトの実際の場所にリンクできるというものでした。それでも、これが正しいアプローチであるかどうか、私は興味がありますか?

(それが正しいアプローチである場合、それを行う方法に関する実際の bzr の例のための余分なブラウニー ポイント)