1

私は2つの関連するリポジトリを持っています。1つはリークしてはならない多数の機密ファイルを含むマスターで、もう1つは機密ファイルとディレクトリを除外するために--filemapを使用してhgconvertで作成された「public」バージョンです。

機密ファイルに影響を与えないマスターへのさらなる更新をスレーブにプッシュ可能にし、スレーブへの更新をマスターがプル可能にしたいと思います。現在、これは発生しません。これらは「無関係な」リポジトリと見なされるためです。

これがGitで可能であり、Mercurialでは不可能な場合、移行は可能ですが、Windowsマシンで一部の開発が行われるため、厄介なことになります。スレーブはまだアクティブな外部使用を確認していないため、必要に応じて、スレーブを削除して別の方法で再作成することができます。どうしても必要な場合は、マスターを完全にダンプしてスレーブから再クローンを作成し、機密性の高い部分をすべて完全にバージョン管理しないままにすることも可能ですが、これらのファイルの一部があるため、これを行う必要はありません。変化しているので、それらの変化を追跡したいと思います。

誰か良いアイデアはありますか？

更新： Gitのドキュメントを調べてきました-「これらを除くすべてのファイルをプッシュする」コマンドは、Gitステージング領域を使用して簡単に実装できますか？

更新2：これは私には役立ちませんが、同様の問題を抱えている人に役立つ可能性があります：hg convert --filemap繰り返し使用でき、マスターへの更新のみを追跡しますが、これは、宛先リポジトリがファイルシステムを介して書き込まれ、勝った場合にのみ機能します有線で動作しません。もちろん、それは反対方向にも役立ちません。

4

3 に答える 3

1

最も簡単な解決策は、おそらく「slave」のクローンを「master」内に配置することです。内部クローンは外部クローンによって無視されます。したがって、シークレットファイルに変更をコミットするときに、それらをパブリックファイルと混合するリスクはありません。押したり引いたりするのは通常のように機能し、内側と外側の2回行う必要があります。

または、「スレーブ」を「マスター」に強制的に引き込むこともできます。これにより、2つのルートリビジョンを持つリポジトリが作成されますが、それは問題ではありません。マージ後、混合リポジトリが作成されます。2つのリポジトリが関連するようになったため、新しいチェンジセットを「スレーブ」からプルインできます。警告は表示されません。

混合リポジトリ内のパブリックファイルを変更する場合は、最初に、「スレーブ」リポジトリからの変更セットに更新されていることを確認する必要があります。そうしないと、コミットできず、新しいチェンジセットが「スレーブ」になります。したがって、[s3]にいる場合：

... [s1] --- [s2] ---[s3]
            /
... [p1] --/

パブリックファイルを更新する場合は、最初に[p1]に更新する必要があります。

% hg update p1

次に編集してコミットします

% hg commit -m 'Public change'
(created new head)

履歴グラフは次のようになります。

... [s1] --- [s2] ---[s3]
            /
... [p1] --/-[p2]

[p2]を「スレーブ」にプッシュする必要があります。

% hg push p2

そしてそれを[s3]とマージします：

% hg merge

その後、あなたは得るでしょう

... [s1] --- [s2] ---[s3] --- [s4]
            /                /
... [p1] --/-[p2] ----------/

その他の解決策は、MercurialwikiのNestedRepositoriesページの下部にあります。Mercurial 1.3ではサブレポ拡張が行われていると思いますが、確認する必要があります（リリース日は7月1日です）。

于 2009-05-21T00:55:34.167 に答える
1

コメントボックスで表示されるよりも多くのスペースが必要だと思います...:-)

内部リポジトリの意味を説明してみましょう。'slave'と'master'の2つの通常の別々のリポジトリがあります。すべてのパブリックファイルを「slave」に配置し、シークレットファイルを「master」に配置します。

master/
  secret-file.txt
  another-secret.txt
  more-secrets.jpeg

slave-clone/
  public.png
  more-public.txt

次に、新しいクローンを作成してそれらを結合します。

% hg clone master master-clone
% cd master-clone
% hg clone ../slave slave-clone

これで、「master」のクローン内に「slave」のクローンができました。

master-clone/
  secret-file.txt
  another-secret.txt
  slave-clone/
    public.png
    more-public.txt
  more-secrets.jpeg

このリポジトリでは、ディレクトリを変更する場合を除いて、すべてのMercurialコマンドで「slave-clone」が無視されていることがわかります。だからあなたはすることができます

% echo 'evil plans' > plans.txt
% hg add plans.txt
% hg commit -m 'Secret stuff'

したがって、外部リポジトリでコミットを行うことになります。いくつかの公開コンテンツを編集するには、通常のように「slave-clone」と入力してそこでコミットします。

「スレーブ」クローンと「マスター」クローンの間は、通常のようにプル/プッシュできます。これは、通常のクローンだからです。プロジェクトはシークレット/パブリックファイルではないということですが、ネストされたプロジェクトと見なすべきではありませんが、2つのディレクトリに分割するために、この区別を行うことをお勧めします。

すべての公開ファイルをシークレットファイルのサブディレクトリに限定しても問題ないと想定していることに注意してください。'slave-clone'の名前を'public'や'announcements'などに変更した場合、あまりにもフェッチされているようには聞こえないと思います:-)

そうしないと、ファイルを1つのディレクトリにシンボリックリンクすることでリポジトリに「参加」できるように、多数のシンボリックリンクを使用して何かを実行できる可能性があります。

于 2009-05-22T22:59:58.540 に答える
1

さて、本当の答えは、「Mercurialはあなたが望むことを行うことができない」（リポジトリとそのリポジトリの厳密なサブセットであるブランチの間の同期をとることです）であるように思われます。パッチキュー。Gitは持っているかもしれませんが、そのWindowsポートはまだ本番環境で使用する準備ができていないので、私はそれをそれほど深く調べませんでした。

しかし、比較的わずかな歴史の損失で、公的部分と私的部分を別々のリポジトリに分割できるようにプロジェクトを再編成することが可能であることが判明しました。（実際、私たちがそこにいる間、それは3つの方法に分割されました-パブリックセクション、サブディレクトリに配置したパブリックだがマシン固有のセクションlocal/（したがって、ほぼ同じ仕様のマシンの大部分にクローンを作成できますいくつかの奇妙なブランチの余分なブランチを維持してマージする必要があります）、およびサブディレクトリに配置したプライベートセクションprivate/。）トリックは、クリーンなスレーブをマスター内に配置しようとせず、プライベート/ローカル部分を分割することでした。マスターから取得し、マスターマシンのスレーブリポジトリ内に（疑似）サブリポジトリとして配置します。

ステージ1は、ファイルをprivate/とlocal/ディレクトリに移動し、マスターリポジトリから削除し、他のマシンで置換シンボリックリンクに問題があった場合に必要に応じて.hgignoreに追加することでした。ありがたいことに、この方法で移動しなければならなかったものの約95％は場所に依存せず、残りは手作業で管理できました。その後、これら2つのディレクトリは独自のリポジトリになりました。

基本的にすでに行ったステージ2：プライベートデータのすべてのトレースが削除されたリポジトリのパブリックバージョンを作成するためにhg convert使用します。--filemap（これには実際に少しのファイルマップ調整が必要でした。現在のプライベートデータファイル名だけでなく、過去に持っていた可能性のあるファイル名もすべて除外する必要があります。ファイルの移動/名前変更を追跡するMercurialの機能は完全に堅牢ではないようです。 。）

この時点で.hg/、マスター上のディレクトリがバックアップの場所に移動され、クリーンアップされたパブリックリポジトリから新しいプルが作成されました。次に、すべてが機能していることを確認するためにテストを実行し、新しいベースリポジトリと選択したリポジトリをスレーブマシンに複製し始め、localそれらをテストしました。シンボリックリンクが機能しなくなった場所をいくつか調整する必要がありましたが、すべて問題ないようです。 （ほとんどの場合、Windowsボックスですが、不思議なことにLinux側では、空き時間があるときにシンボリックリンクがたどられなかった理由を掘り下げる必要がありますが、問題は解決しました。 1つの特定のファイルが自動的に再生成される可能性があり、実際に再生成される必要があることが発見されました）。

于 2009-05-24T17:43:09.327 に答える