MercurialリポジトリがありますmyProject：

useful.jsこれで、いくつかの便利なクラスが含まれるファイルになりました。私はそれを複数のプロジェクトで使用しているので、独自のリポジトリがあります。

他の人がチェックアウトしてuseful、ファイルと例とreadmeを見て、気に入ったらuseful.js自分のプロジェクトにコピーして利用できるようにするという考え方です。

useful.jsいくつかのプロジェクトで使用されているので、同期を維持するための推奨される方法は何ですか？最上位フォルダに存在するuseful.js 必要がある制限がありますmyProject。つまり、ネストすることはできません。これにより、サブリポジトリを使用するのが難しくなります（いずれの場合でも、example.jsandのような他のファイルを取得しますREADME）。

もう1つ注意すべき点は、リポジトリには、、、およびusefulのいくつかのブランチがあることです。を使用する私のプロジェクトには、ブランチ、、およびもあります。のブランチを切り替えるときはいつでも、スイッチもブランチするようにしたいと思います。そうでなければ、私はおそらくシンボリックリンクで生きることができるでしょう。defaultversion1version2useful.jsdefaultversion1version2myProjectuseful.js

この状況は特に珍しいことではないようです。他の人はそれをどのように扱いますか？フックを書いて、updateブランチを切り替えているかどうかを確認し、それに応じて切り替えますか？プラスフックcommit、、？（基本的に、単一ファイルのサブリポジトリの動作を複製します）？pushpull

乾杯。

Mercurialリポジトリにいくつかの大きな変更を加えようとしています。ラストリゾートの機能を使用するので、私は愚かなことをしていないというアドバイスと安心を探しています。

わたしはどこにいますか：

これらすべてのファイルの完全な履歴を持つMercurialリポジトリがあります。

ソースはMercurialリポジトリです。シークレットサブシステムフォルダには、社内に保持したい知的財産であるコードが含まれています。未分類のサブシステムフォルダには、保守のためにサードパーティにアウトソーシングするコードが含まれています。共通ファイルフォルダには、両方のサブシステムが依存するコードが含まれています。所有権は保持しますが、第三者と共有したいと考えています。

もちろん、リポジトリ全体をサードパーティの会社にプッシュすることはできません。サードパーティはあまりにも多くを見るでしょう。

私がなりたい場所：

サブリポジトリを 読んだ ので 、これ は私がする必要があると思うところです：

3つのサブリポジトリ（secret_subsystem、unclassified_subsystem、common_files）があります。この推奨事項により、/sourceレベルに他のファイルがないことを確認してください。

アウトソーサーに、自分のマシンのソースレベルで新しいリポジトリと、対応する2つのサブリポジトリを作成してもらいます。

unclassified_subsystemとcommon_filesをアウトソーサーにプッシュし、必要に応じてunclassified_subsystemをプルバックし、必要に応じて新しいcommon_filesリポジトリーをプッシュします。

履歴の維持：

すべてのサブシステムについて、可能な限りコミット履歴を維持したいと思います。

これを行うには、サブリポジトリごとに1回ずつ、hgconvertextensionコマンドを3回実行します。各サブリポジトリに属する​​ファイルのみにフィルターをかけます。また、ファイルを./common_files/foo.pyから./foo.pyに移動するためにファイル名をマップする必要がある場合もあります（たとえば）。

私の質問：

1）リポジトリをサブリポジトリに分割することは、セキュリティを実装するための合理的な方法です。サードパーティは一部のファイルしか表示および編集できないということですか？

2）hg convert履歴を維持しながら、既存のリポジトリからサブリポジトリを作成するための合理的な方法を使用していますか？

3）hg convertのフィルターは（a）フィルターされたリポジトリにないファイルに関するすべてのコミットメッセージを取り除きますか？フィルタリングされたリポジトリにないファイルのすべての差分を除外しますか？

別の暗黙の質問があります：私は傷ついた世界に向かっていますか？もしそうなら、私は単にファイル履歴の保持をあきらめるか、あるいはそれらを別々のリポジトリにして、リポジトリ間のコミットを忘れます。

複数の環境に展開する継続的インテグレーション ビルド サーバーとして Bamboo を使用しています。Red Gate SQL Compare と Data Compare を使用して、Bamboo NANT スクリプトを使用して SQL コードの展開を統合しようとしています。TEST 環境はリポジトリの「TEST」ブランチのコードであり、STAGE 環境はリポジトリの「デフォルト」ブランチのコードです。

私たちの SQL とコード ベースは、個々の Mercurial リポジトリ (Project_SQL) と (Project) に分かれています。各レポにコミットする方法は異なります。Project_SQL リポジトリでは、開発は直線的です。各開発者は TEST ブランチから分岐し、dev ブランチ (Branch_1) を作成して変更に取り組み、dev ブランチにコミットして、TEST ブランチにマージします。TEST ブランチの最新のテスト済みの作業ヒントを使用して、TEST の先頭からデフォルト ブランチに移動するだけです。例: 0、1、2、3 がコミットで、0、1、3 がテスト済みで合格の場合。デフォルトでは 0 と 1 のみです。プロジェクト リポジトリでは、開発者は、Production にプッシュされた、デフォルトから最後にタグ付けされたバージョンのブランチを作成し、dev ブランチ (Branch_2) を作成し、変更に取り組み、dev ブランチにコミットし、変更を TEST にマージします。

要件は、Bamboo のポーリング間隔でコード コミット (Project) がある場合、SQL リポジトリを更新し (Project_SQL)、コードをコンパイルしてテストを実行する前に SQL の変更をデプロイする必要があることです。ポーリング間隔で SQL の変更のみがある場合、SQL がデプロイされ、コード内のテストも実行されます。

次のプロセスと要件が整っていれば、SQL リポジトリをコードのサブリポジトリとして使用できることがわかりました。または、Bamboo 内で依存関係が設定された別の計画を立てることもできます。

推奨される方法は何ですか、またはより良い方法はありますか?

他のアプリケーションと共通の 2 つのモジュール「common」および「common-www」を使用するアプリケーション「myapp」があります。

これらは、マスター リポジトリ内のシン シェルとして配置されます。

各サブレポは、「本番」リポジトリと「トランク」リポジトリを使用して、安定した/デフォルトの構成としてセットアップされます。

安定版 (「運用」) のシンシェル マスターの .hgsub ファイルは次のとおりです。

マスター リポジトリ自体は次の場所にあります。

これは素晴らしいことです。アプリケーションとサブモジュール全体で一貫したバージョン管理を備えた単一のマスター リポジトリがあります。

問題は、.hgsub ファイルが異なるリポジトリを指す必要があるため、マスター リポジトリの安定した/既定のビューを維持できることです。

.hgsub ファイルに絶対パスを配置する必要があるため、完全に独立した 2 つのシンシェル マスター リポジトリ (開発用と運用用) ができてしまい、リリース サイクル中に開発から運用に変更をプッシュすることはできません。

このリモート ホスティングのマスター リポジトリ アプローチは、共有ライブラリの典型的なものですか? 別の作業方法をお勧めできますか (hgsub パスが絶対パスであるリモート ホスティングに関して)?

何か考えはありますか？

私はと呼ばれるリポジトリを持っておりmain、その下にいくつかのサブリポジトリがあります。最初にスーパーリポジトリを作成したときmain、既存のリポジトリを取得してmainフォルダにコピーし、サブリポジトリ.hgsubの名前を示すファイルを追加しました。

現在、このmainフォルダは会社のファイルサーバー上にあり、によって提供されてhgServiceおり、新しいリポジトリを追加する必要があります。広い緑の世界でこれはどのようにシームレスに行われますか？

mainローカルマシンにクローンを作成した場合、それhg init newrepoをクローンにコピーしmain、適切なエントリを追加して.hgsubコミットできますが、プッシュできません。の行に沿ってエラーが発生しますhttp error 404 path not found。わかりました。十分に公平なので、エントリをhgServiceのweb.confファイルに追加して再起動します。今、私はまあまあのような別のエラーを受け取りますsubrepository 'newrepo' doesn't exist！追加しようとしています！

そのため、私はついに故障し、サーバーにRAdminを実行し、手動でnewrepoを作成し、それをサービス対象のリポジトリに追加して、main変更hgServiceをコミットする必要がありました。これは私には非常に汚いように思えます。さらに困難なことに、サーバーの作業ディレクトリの状態が約6か月古くなっていたため、最新のリビジョンに更新するために無数の問題を解決する必要がありました。

これを行うためのより良い方法が必要です..私はユーザーを共同にRAdminingさせることはできません。新しいリポジトリが必要になるたびにVCSサーバー？右？

ソースからプルせずに、サブリポジトリを使用してリポジトリのクローンを作成する方法を理解しようとしています。チュートリアルや例を読んだことがありますが、私のMercurialの知識は暫定的なものです。

現在、.hgsub構造は次のタイプのリストです。

投稿への回答を読むサブリポジトリを再度プルせずにローカルクローンを作成するにはどうすればよいですか？リストに変えてみました

hg update -R rev

私が何をしても、ローカルのサブリポジトリのコンテンツではなく、常にソース（ssh）からプルすることになります。

注：元のリポジトリを更新しようとすると、重複パスに関するエラーが発生しました。このエラーは、.hgsubファイルの変更を元に戻したときにのみ消えました。

他に何を試しましたか：

アイデア：コピーアンドペーストのようにリポジトリの複製コピーを作成し、ハードリンクを使用します。それは良い考えでしょうか？コピーを変更したときに、元のファイルに変更を加えてしまうことはありませんか？

別のアイデア：ハードリンクを使用して.hgフォルダーのクローンを作成し、残りのコンテンツをコピーするだけですか？

誰かがこの問題の解決策を持っていますか？

Mercurialリポジトリで階層構造を使用したいと思います。

構造

.hgsub

次に、私の同僚はsub1リポジトリのみを変更し、メインリポジトリはありません。
同僚が行った変更よりもsub1の変更をどのように判断できますか。メインリポジトリでコミットされていない場合、hgpullはこれらの変更を認識しません
。

または多分それは間違った構造であり、私は同僚にsub1のデータを含むメインリポジトリを提供しなければなりませんか？

サブレポのあるレポがあり、やりたいですhg serve。

他のコンピューターで、私は試しました

シナリオ 1: 元のレポの .hgsub に次の形式の行があった場合:

私は他のコンピュータに乗りました：

（サーブコンピュータはその後待つだけです）

(そして、new_repo 内の sub_repo_1 のみ。更新、プルを試みましたが、エラーが発生しました)

実際に sub_repo_2 を個別に複製しようとしましたが、エラー 404 (送受信コンピューターのボット) が発生し続けました。

シナリオ 2: .hgsub の行を

hg serve は subrepos を提供できませんか? または - 私は何を間違っていますか?

注: サブレポ内の hgrc ファイルを毎回 .hgsub 内のパスと一致するように更新しました。

私たちは、いくつかのプロジェクトが使用する予定の社内フレームワークを開発しています。アイデアは、フレームワーク全体を各プロジェクトのリポジトリの水銀サブリポジトリとして追跡することです。これにより、次のサブレポ ツリーが作成されました (シンシェルリポジトリを参照)。

• これはあなたにとって意味がありますか？サブリポジトリを含まないこれらの依存関係を処理するためのより良い/より簡単な方法はありますか?
• 具体的には、両方の CommonLib サブリポジトリを持つことは理にかなっていますか?
• そうでない場合、Project が FrameworkMaster/CommonLib を使用することは理にかなっていますか? 依存関係がより複雑な場合、これは面倒になる可能性があります。
• どこで機能ブランチを開きますか? マスターに？関連するサブリポジトリのみ？
  • マスターに機能ブランチがない場合、リポジトリを複製するたびに、最後のコミットのサブレポの状態を取得することになり、任意のサブレポが任意の機能ブランチに配置される可能性があります。非常に紛らわしいです。
  • マスターにフィーチャー ブランチがある場合でも、少なくとも 1 つのサブリポジトリにフィーチャー ブランチが必要です。

一般に、このソリューションは扱いにくいように思えます。助言がありますか？

TortoiseHg で次のようなサブリポジトリ構造を持っています。

MainFolder は bitbucket のプライベート リポジトリです SubFolder1 は bitbucket のプライベート リポジトリです SubFolder2 は bitbucket のプライベート リポジトリです

MainFolder 内のファイル .hgsub は次のようになります。

MainFolder 内のファイル .hgsubstat にも有効な GUID とサブリポジトリ名があります。

問題は、MainFolder の bitbucket にプッシュしようとするたびに、最初に MainFolder、次に SubFolder1 をプッシュしますが、SubFolder2 に到達すると、TortoiseHg は「中止: リポジトリは無関係です」というエラーをスローします。

Bitbucket で MainFolder リポジトリを確認すると、実際には SubFolder1 のコンテンツが含まれています (サブリポジトリとしてリストされているはずです)。

MainFolder が親リポジトリとして正しくアップロードされ、SubFolder1 と SubFolder2 が bitbucket のサブリポジトリとしてリストされるように、これを修正するにはどうすればよいですか?