問題タブ [subrepos]

私は、顧客固有の小さなアプリケーションを多数作成する会社で働いています。私たちは少数の開発者ですが、ほとんどの場合、プロジェクトごとに 1 人の開発者しかいません。

現在、すべてが単一のリポジトリに格納されています。

プロセスは簡単です。

1. 開発者が顧客のために新しいプロジェクトを引き受ける
2. プロジェクト用の新しいフォルダーを作成します
3. 新しいプロジェクトのコード
4. 別のプロジェクトでメンテナンスを行う
5. メンテナンス プロジェクトへの更新のチェックイン
6. 新しいプロジェクトでの作業が増える
7. 新しいプロジェクトをチェックイン
8. お客様へお届け

タグ付けも分岐もありません。以前のバージョンは、日付に基づいてチェックアウトされます。

このプロセスは長年にわたってうまく機能してきましたが、現在のツール (CVS) にはいくつかの問題点があります。

• 遅い。何も変更されていない場合でも、チェックアウトには数分かかります。履歴はサーバーに保存されるため、差分に時間がかかりすぎます
• 新しいプロジェクトの追加。CVS で作業したことがあれば、次のようなことを知っているでしょう: フォルダーを追加、フォルダーにファイルを追加、次のフォルダーを追加...
• 明らかなエラー (バイナリのチェックインなど) を取り消す方法がない
• 必要なリファクタリングをさらに困難にする名前変更のサポートはありません。

私はしばらくの間 Mercurial を個人的に使用してきましたが、それをすべての開発者に拡張したいと考えています。

私はそれをすべて間違っているかもしれませんが、私たちの組織に実装する方法を理解していないことがいくつかあります.

CVS コミットは現在のフォルダーのみですが、mercurial ではリポジトリ全体です。私たちの場合、あるフォルダーでメンテナンス作業をコミットすると、別のフォルダーで未完成のものもコミットされることを意味します。（変更されたフォルダーで実行できると思いhg ci ./**ますが、マージでは許可されていません。少なくともドキュメントにはそう書かれていますIf you are committing the result of a merge, do not provide any filenames or -I/-X filters.）

Mercurial での一般的な方法は、プロジェクトごとに 1 つのリポジトリを持つことです。

プロジェクトごとに 1 つのリポジトリで問題ありませんが、次のような問題が発生します。

中央サーバーで複数のリポジトリを管理する方法は?
開発者が新しいプロジェクトを作成した場合、最終的に変更をプッシュする必要があります。やってるだけ

hg push http://localhost:8000/Customer1/NewProject

醜いスタック ダンプで hg-webserver をクラッシュさせ、クライアントをハングさせます。

私が理解している方法は、開発者がサーバーシェルにアクセスして、新しいリポジトリを構成ファイルに追加し、hgweb を再起動する必要があるということです。

別の方法は、SSH または共有を使用することです (ファイル共有の代わりに SSH を使用する利点はありますか?)

機能しますが、一部の開発者にとっては少し複雑です

すべての開発者は、すべてのプロジェクトを持っている必要があります。
（実際にはすべてではありませんが、多くのプロジェクトがリンクされているため、それらが存在する必要があり、すべてを持っているのが最も簡単です）

多くの既存のプロジェクトと新しいプロジェクトが毎週追加されるため、すべてのプロジェクトを一度にプルし、新しいプロジェクトを複製する方法が必要です。

サブレポが「グローバル」プルを解決できると考えていましたが、ドキュメントの次の行はショーストッパーです

「コミットすると、Mercurial はプロジェクト全体とそのサブリポジトリの状態の一貫したスナップショットを作成しようとします。これは、最初に変更されたすべてのサブリポジトリでコミットを試み、次にすべてのサブリポジトリの状態を記録することによって行われます。」

グローバルコミットの単一リポジトリの問題に戻ります。

(いくつかのバリアントを試してみましたhg ci .hgsub .hgsubstate <subrepo>が、.hgsubstate は完全なコミットでのみ更新されるようです。他のユーザーはhg pull --update、プロジェクト フォルダーに明示的に指定しないと、プロジェクトの変更を確認できません)

私の現在の考えは、すべてのプロジェクトをプルするバッチファイルをルートに置くことです

私たちの組織で水銀を使用する方法について、他に何かアイデアはありますか?

編集

返信いただきありがとうございます。現在、プロジェクトごとに 1 つのリポジトリがどのように機能するかを評価しています。最上位にバッチファイルを置きます

複数のサブリポジトリを含むMercurialリポジトリがあります。リポジトリには、リポジトリとサブリポジトリ内のプロジェクトを含むVisualStudioソリューションがあります。

リポジトリ内のメインプロジェクトへの変更と、ソリューション内の依存関係プロジェクトの1つへの変更を必要とする新しい機能を実装したいとします（たとえば、依存関係に新しい共有インターフェイスを追加し、メインプロジェクト）。

次に、変更をコミットしたいのですが、未完成で後でマージされるため、新しい名前のブランチにコミットします。tortoiseHgを使用して、作成する新しいブランチを指定して、リポジトリ内の変更をコミットします。次に、コミットはサブリポジトリの変更をコミットしますが、私のテストでは、リポジトリに新しいブランチを作成せず、現在のブランチに変更セットを追加するだけです。

サブリポジトリへのコミットを明示的に実行し、その時点でブランチ名を指定できますが、リポジトリ全体の変更セット全体を一度に各リポジトリの新しいブランチにコミットして、ワークフローをよりクリーンにする方法を望んでいました。これは可能ですか？

私は水銀にかなり慣れていません。このテーマに関する多くのトピックを読みましたが、自分がやろうとしていることを達成できるかどうかはまだわかりません。

基本的に、メイン リポジトリとそのサブリポジトリからブランチの現在のリビジョンを 1 つのコマンド (メイン リポジトリに作用する) で複製することに興味があります。私はすぐにそれをよりよく説明しようとします。

コードをモジュールに分割したとしましょう (以下の例では 1 つのモジュールのみ)。各モジュールを独自のリポジトリに配置し、マスター リポジトリ (.hgsub を含むリポジトリ) を接着剤として使用して、すべてのサブリポジトリを所定の位置に保持したいと考えています。マスター リポジトリには .hgsub と、(1)hg archive事前定義されたディレクトリ内の各サブリポジトリと (2) コードのソース外ビルドを実行するスクリプトが含まれています。すべての開発、コミット、プッシュ、プル、マージは、個々のサブリポジトリで行われます。

ここまでは順調ですね。hg clone main予想どおり、サブレポのデフォルトブランチの現在のリビジョンを取得した場合。

しかし、私のコードを 1.0.0 というリリースに出荷する準備ができたとしましょう。私は次のようにします。

そして、ここで問題が発生します。マスターリポジトリを変更して、実行時にデフォルトの現在のリビジョン、または最終的にはサブリポジトリの 1.0 ブランチを取得するにはどうすればよいhg cloneですか?

私はこれがうまくいったと言ったでしょう。

しかし、私hg cloneがメインレポになると、

私がやりたいことを達成する方法はありますか？

ありがとう。

クイック アップデート: 質問を投稿してからわずか 1 分後に、今まで見たことのない回答を見つけました。そこでは、次の構文を使用することをお勧めします

#branchnameの代わりに使用して#revision。したがって、私の例では、次のように動作するはずです (ブランチ 1.0 の場合)。

しかし、私hg cloneがマスターレポを取得すると、次のようになります。

私はUbuntu 10.04、mercurial 1.4.3-1に取り組んでいます。提案？

-- ディラン

私は水銀を初めて使用します。このトピックについて多くのことを読みましたが、明確な答えを見つけることができませんでした。

Mercurial ガイドには次のように書かれています。

リポジトリ wiki ページには、「リポジトリ ルートの .hg ディレクトリと共存するすべてのファイルとディレクトリは、作業ディレクトリに存在すると言われています」と記載されています。

ここで、サブレポをメインレポに「リンク」するには、次のようにします。

上記の定義は、 (1) を実行したときに実際に のコピーを作成していることを意味しますか?? subrepoそれとも、へのシンボリックリンクを作成してい../subrepoますか? の出力によるとls、実際のコピーです。しかし、それは私にはとても奇妙に聞こえます...誰かがこの主題に少し光を当てることができれば、私は感謝します.

私のプロジェクトは、次の場所にあるコードで構成されています

現在、これらの各フォルダは完全に独立した Mercurial リポジトリです。プロジェクト A は常に変更され、ライブラリ B とライブラリ C はめったに変更されません。

私は現在、プロジェクト A の各バージョンがリリースされるたびにタグを付けており、(思い出すと) ライブラリ B および C リポジトリに対応するタグを付けています。

サブリポジトリを使用してこれを改善できますか? ライブラリ B と C をプロジェクト A のサブディレクトリにする必要がありますか?

ライブラリ B と C がプロジェクト A のサブディレクトリでなければならない場合、ライブラリ B を使用するがプロジェクト A とはまったく関係のないプロジェクト D を開始したい場合はどうすればよいですか?

コードの変更に取り組んでいるときに、それ自体がサブリポジトリであるリポジトリ内の共有ライブラリ コードに対応する変更を加える必要がある場合があります。変更をコミットしたいときは、親リポジトリで行い、Mercurial はサブリポジトリで対応するコミットを行います。

しかし、私は最近、MQ を使用して自分自身の変更履歴をより適切に追跡し、実験の自由度を高め、大規模なリファクタリング作業をより安全に行えるようにしました。親リポジトリとサブリポジトリの両方で MQ を有効にしています。

上記のシナリオで、新規または既存の MQ パッチに「コミット」すると、サブレポが無視されると想定するのは正しいですか? これは私のテストで起こっているようです。これは、サブレポでパッチ キューを手動で管理する必要があるということですか? これはすぐに扱いにくくなります。

これがうまくいかない場合は、それで問題ありません。ワークフローを調整して、クロスレポ作業を行うときに MQ を回避できます。

更新:このスレッドによると、現時点では「サポートされていない」可能性があるようです: https://www.mercurial-scm.org/bts/issue2499

私は次のことを試しました：

1. サブレポの変更を手動でコミットしました。
2. サブリポジトリ コミットからのハッシュを使用して、親リポジトリの .hgsubstate ファイルを手動で更新しました。
3. 親リポジトリを qrefresh しようとしました。

アイデアは、手動で行う必要がある場合でも、親リポジトリからコミットを取得して、常に正しいサブレポ バージョンと同期できるようにすることでした。残念ながら、Mercurial はここで私を保護したいと考えているようで (そうあるべきです!)、qrefresh しようとすると次のように表示されます。

物事を「修正」するために、親リポジトリで hgfinish の後に空のコミットを行い、物事を同期させます。しかし...それはばかげているようで、コードの歴史を理解するのが難しくなります。

まあ、私は石器時代に戻って、サブリポジトリが関係するワークフローで MQ を使用するのをやめるだろうと思います。

私が開発しているプロジェクトは、CodeIgniterから構築されています。プロジェクトの主要部分は私が作成しているプラ​​イベートシステムですが、関連するすべての機能を取得するために、ソース管理に追加したいと思います。今はMercurialを使用しているので、hg initビット全体を実行したので、リポジトリを設定しました。

さて、私がやったことの1つは、このプロジェクトで使用するCodeIgniterのライブラリを作成することです。このライブラリを開いてみたいので、そのための別のリポジトリが必要です。

CodeIgniterライブラリの開発に慣れていない人のために、ここにリファレンスがあります：

このプロジェクトの過程で、おそらくさらにいくつかのライブラリを開発する予定です。そのため、リポジトリをまとめずにアプリケーションフォルダにダンプすることはできません。

私がしたことはこれでした：

これらのフォルダの両方に、リポジトリを作成しました。私がやりたいのは、プロジェクトリポジトリがライブラリリポジトリを自動的に参照するようにすることです。これにより、前に説明したように、プライベートリポジトリとパブリックリポジトリを持つことができます。

これを行う主な方法は、私が読んだことですが、サブリポジトリを使用することですが、ネストされたものの例しか見つけることができません（とにかく不明です）。svn：externalsのような別のリポジトリを参照させるにはどうすればよいですか？

サブリポジトリと、変換拡張機能とファイルマップを使用して既存のフォルダーを Mercurial リポジトリからサブリポジトリに抽出する方法について読んでいます。私はこれをうまくやることができます。次のフォルダー構造がある場合:

SubFolder のサブリポジトリを作成できます。ほぼ同じ方法で、他のすべてを別のリポジトリに抽出できます (この例では、2 番目のリポジトリには root.txt ファイルのみが含まれます)。その後、SubFolder リポジトリをサブリポジトリとして 2 番目のリポジトリに追加できます。しかし、両方のリポジトリには完全な履歴がありますが、これらの履歴はリンクされていません => ルート リポジトリを以前の状態に更新しても、サブリポジトリはその時点であるべき状態になりません。一貫性のある古いリビジョン (ルートとサブリポジトリの両方が自動的に更新される) への更新は、サブリポジトリを既に認識しており、.hgsubstate ファイルを持つリビジョンに更新する場合にのみ機能します。

そして、私が考えた代替手段は、現在のリポジトリの SubFolder のファイルを忘れて、SubFolder で新しいリポジトリを開始し、同時に .hgsub ファイルを追加することでした。ここで達成したいのは、この時点からサブリポジトリを使用して作業することですが、SubFolder のファイルは現在のリポジトリの履歴に残っているため、(サブリポジトリを分離する前に) 古いリビジョンに更新する方法がまだあります。

ただし、これは機能しません: Mercurial のファイルを忘れて、新しいレポを開始し、現在のレポでサブレポとしてリンクし、サブレポが存在する前に古いリビジョンに更新すると、次のエラーが発生します:

ここでの問題は、サブレポを認識していなかった古いリビジョンに更新するときに、この更新でファイルをサブフォルダーに配置しようとすることです。しかし、この SubFolder はまだ別のレポ (.hg ディレクトリを持っています) であり、メインのレポにはそれに関する記憶がありませんが、アップデートはレポであるため、SubFolder にファイルを配置したくありません。

とにかくこのエラーを回避する方法はありますか、または既存の Mercurial リポジトリ内の特定のフォルダーにサブレポを使用するように切り替えて、履歴をそのまま維持する (そして両方の履歴をリンクする) より良い方法はありますか?

かなり標準的なソースツリーアプローチと水銀サブリポジトリを使用しているマスタープロジェクトがあります。

さて、最近、Sub2にはSub1からのコードが必要であると判断されたため、この新しい依存関係構造を調整する必要があります。

もちろん問題は、上記と同じアプローチに従い、Sub1をSub2のサブリポジトリとして追加すると、この醜い状況になってしまうことです。

マスターには、Sub1の2つの独立したコピーがあります。

したがって、サブリポジトリ（=のRHS）を参照するときに相対パスを使用する必要があることはわかっていますが、理解しているので、ここでのシナリオには役立ちません。LHSをマスターリポジトリの外でライブにする方法はないと思います。これが私がここで本当に必要としていることだと思います。

私はこれを修正する方法についていくつかのアイデアを持っていますが、どれも私にぴったりではなく、より良い方法が必要だと思います。私の理想的なソリューションでは、複数のコピーを持っているというペナルティを支払うことなく、複数のプロジェクト間で同じサブリポジトリを共有できます。これは、ここでの私のシナリオでは無駄で非効率に思えます（さらに、Sub1に依存するすべてのプロジェクトで、個別にリビジョンを作成するのではなく、同じhgリビジョンを使用するようにしたい）

1. マスターのサブリポジトリとしてSub1を削除し、マスターソリューションの相対パスを変更して、二重にネストされたSub1を参照します。このパス構造は恐ろしいだけでなく、Sub1に依存するマスターにSub3を追加した場合でも、Sub1のコピーが2つあります。

2. Sub1のコピーをコンパイルし、\libディレクトリにチャックするだけです。Sub1はまだいくつかのチャーンが発生しているので、ソースバージョンに対してビルドしたいと思います。新しいバイナリを常にソースツリーにコピーする（そしてツリーを肥大化させる）という税金を払いたくありません。

3. どういうわけかSub2のSub1への依存を破ります。リポジトリのアーキテクチャに基づいて、これはおそらく起こらないでしょう。Sub1には、非常に汎用的な共有ライブラリコードが含まれています。Sub2には、2つの非常に別個のプロジェクト（クライアントSDKとサーバー実装）で必要なWCFサービスコントラクト/インターフェイス/タイプが含まれています。この時点で、これらのリポジトリを分離しておくことは理にかなっています。

多分私はこれが間違っていると思っています...あるいは多分私はいくつかのhgトリックに気づいていません。

どんな助けでも大歓迎です。

これは長い投稿になるだろう...前もって申し訳ありません。

「プロジェクトブランチごとのリポジトリ」をまとめる方法と、それがチームに与える影響について頭を悩ませています。

現在、

• ネストされたチェックインのコードを再帰的にチェックインできますが、hg ステータスはネストされたリポジトリ内のファイルの変更に関する多くの情報を提供しません
• 私、そして同じプロジェクトに取り組みたいすべてのチームメンバーは.hgrc、チェックインをできるだけ簡単かつ自動化するために、サブリポジトリのファイルを手動で編集する必要があるようです。
• 再帰的にチェックインできますが、再帰的にチェックアウトはサポートされていません。

それはHgの能力の正しい分析ですか？

私が見た平均的な開発チームが生産性を維持しながら処理できるよりも、スティックシフトコーディング (つまり、コマンドプロンプトをあちこちいじる) がはるかに多いため、そうならないことを本当に望んでいます。私が理解しているように、単一のアセンブリをリファクタリングすると、.hgrcファイルの編集を停止して場所、ユーザー、およびパスワードを追加するため、おそらくチームが停止することになります。いいえ？

そして、Hgが再帰的にプルできないことを本当に再確認したいですか? 私は何かを逃したにちがいないと感じるほどの省略のように聞こえます。

ありがとう！

PS: 勇敢な人も愚かな人も (助けになる場合に備えて)、他のライブラリ モジュールを参照するライブラリ モジュールを参照するプロジェクトの問題を回避するために私が守ってきたメモは次のとおりです (??? に注意してください)。 ? 質問??? それらにちりばめられた...