問題タブ [dvcs]

DVC を使用することには間違いなく多くの利点があり、集中型 VC のように使用できますが、ローカル コミットがあり、小さなグループのためにプロジェクトを非常に簡単にフォークできるため、継続的インテグレーションのサポートが難しくなりますか? CI サーバーによってテストされた最新の変更に誰もがアクセスできるため、互換性のない変更の可能性を最小限に抑えることができます。

私の SVN リポジトリには、リリース サイクルが異なるプロジェクトがいくつかあります。リリースは、SVN の従来のタグ構造を使用して作成されます。リリースで修正すべきバグがある場合、タグからブランチが作成され、バグが修正され、そこからトランクにマージされます。

現在、複数の理由から、SVN から mercurial に切り替えて、中央のプッシュ サイトを使用したいと考えています。

質問: ほとんどコードを共有しない複数のプロジェクトを Mercurial で編成するのに最適な方法はどれですか? プロジェクトごとに 1 つずつ、複数のプッシュ サイトを作成する必要がありますか?

私のリリースタグ、バグ修正ブランチなどを再作成する方法についての説明を回答に含めてください...お好みのバージョンのリポジトリ設計を使用してください。

編集：できるだけ少ない拡張機能をインストールしたいと思います。

編集2:

この SVN レイアウトを考えると:

(ありがとう @bendin! :) )

複数の hg push リポジトリで作業する方が良いですか

枝のために。タグは適切なブランチに折りたたまれます。

または、この例では 2 つのプッシュ リポジトリを使用しますか?

名前付きブランチを使用するため、1 つのリポジトリ内に複数のヘッドがあります。

複数のヘッド リポジトリの利点は、複数のリポジトリでタグを探しに行く必要がないことです。私が見る不利な点は、hg book が複数のヘッドリポジトリを思いとどまらせるように見えることです。あなたは何をしますか？

そのため、この時点でかなりカスタマイズされたドットファイルのセットアップができており、マシン間で同期を維持するためのソリューションを探していました。シンボリックリンクの作成を処理するメイクファイルを含む ~/dotfiles dir (または同様のもの) を持つという考えが気に入っています。rsync/unison/dvcs/whatever を介して dotfiles ディレクトリをマシンからマシンに移動すれば、準備完了です。

この問題は、一部のマシンでファイルがわずかに異なるために発生します。これを追跡する方法が必要です。たとえば、私の .xmobarrc (なじみのない人向けのパネル アプリケーション) には、デスクトップではなく、ラップトップではバッテリ寿命を表示する構成設定があります。

このようなマシンごとの違いでファイルを管理する最良の方法は何ですか?1 つのマシンですべてのマシンに影響するはずのものを変更すると、元に戻すことができます。マージされません。明らかに、rsync/unison/etc とは対照的に、これには git のような DVCS が必要ですが、これを設定する方法がわかりません。

マージ/リベース/チェリーピックを行ったり来たりするマシンごとに1つのブランチを持つマスターブランチ? これは少し面倒に思えます。より良い方法はありますか？

Mercurialは使用していませんが、始めたいので読んでいます。私が広く使用している唯一のSCMシステムはCVSです。Mercurialについて私が読んだことのほとんどは理にかなっており、良さそうです。しかし、私はそれがタグを行う方法に交互にショックを受け、当惑しています。

タグは、チェンジセットの単なるニックネームです（「チェンジセット」とは、実際にはチェンジセットの結果として生じる状態を意味します）。涼しい。タグからチェンジセットIDへのマッピングは.hgtagsファイルに保存されます。またかっこいい。.hgtagsファイルはバージョン管理されています。

何？

これは直感に反する結果をたくさんもたらします。たとえば、タグ付けしたいチェンジセット（たとえば、リリース1.0を形成するコード）をコミットした場合、タグ付け後に再度コミットして、更新されたタグファイルをリポジトリに配置する必要があります。そして、後日、そのタグ付きチェンジセットに更新すると、作業コピーにはそのタグに関する知識が含まれなくなります。私が何らかの作業を行って、新しいブランチを作成した場合（たとえば、バグ修正の場合は1.1に向かって）、そのブランチは、それが成長したタグについての知識を持っていません。手動でコピーしない限り、つまり。

また、元のトランクと新しいブランチの両方で開発が継続され、重要な変更セット（トランクの2.0リリース、ブランチの1.1および1.2バグ修正リリース）をマークするタグが作成されるため、両方のブランチは他方を無視して続行しますブランチのタグ。したがって、あるブランチでの作業を終了し、別のブランチで特定のチェンジセットに切り替えたい場合（たとえば、1.2のバグ修正リリースを終了しましたが、2.0に基づく2.1のバグ修正で開始する必要があります）、今は詰め込まれています。私の現在のチェンジセットは2.0について知りません！

私に何ができる？

• 2.xブランチで作業している人に、2.0の実際のチェンジセットIDを読み取って、それを明示的に使用するように依頼することはできますが、これは恐ろしいことです。
• タグを使用するだけでなく、ブランチに名前を付けることもできます。これにより、2.xブランチの先頭に移動して、新しいタグについて学習し、2.0タグにスキップして戻ることができます。タグとは異なり、ブランチが普遍的に見えると仮定すると、そうですか？たとえそうだとしても、これは不格好なようです。
• リポジトリの外部に単一のグローバルhgtagsファイルを維持し、いくつかのフックを使用して、更新時にコピーをプルし、ローカルコピーを上書きし、コミット時に変更をコピーして戻すことができます。開発者が共有リポジトリに変更をプッシュしているマルチユーザー環境でこれがどのように機能するかはわかりません。ファイル専用の別のリポジトリが必要になる場合がありhgtagsます。
• バージョン管理メカニズムの外部にあるローカルタグを使用できるので、問題全体を回避できます。localtags共有グローバルタグと同様に、開発者間でファイルを同期するメカニズムを導入する必要があります。

これらのソリューションはどれも完全に優れているようには見えません。私は何をすべきか？

ここでの前提は、ブランチごとのリポジトリではなく、単一のリポジトリで名前付きブランチを使用してブランチを管理していることです。私が後者をした場合、状況はもっと良くなるでしょうか？

Visual SourcesafeリポジトリをMercurialに移動する最良の方法は何ですか（すべての履歴を保持することに興味があります）？

ローカルの無視ファイルを hg リポジトリ、つまり .hgignore と機能が似ているがリポジトリにチェックインしないファイルを保持する方法があると断言できたはずです。これは、たとえば、異なる IDE が使用されている場合に、IDE プロジェクト ファイルへの変更を無視するために使用できます。やり方が分からなくて困っています。詳細を覚えている人はいますか？

私はSCMを新しいプログラム用にセットアップするのを手伝っており、現在、VCSを決定しているところです。

この時点での主な候補は、SVN、ClearCase、SVN + DVCS、および単なるDVCSです。

現在、チームはSVNまたはSVN+DVCSのいずれかに傾いています。ClearCaseの費用と管理コストを回避したいのですが、ClearCaseが提供するワークフローとバージョン管理オプションが必要です。DVCSを使用するオプションも提案し、そのアイデアを検討しています。

DVCSについては、Mercurial、Bazaar、Gitを検討しています。チームはSVNに満足していますが、必要な汎用性が提供されるとは思わないため、SVNオプションに加えてDVCSを検討しています。

そのようなセットアップを実行するためのアドバイス（既存のツール、プロセスなど）はありますか？

懸念事項は次のとおりです。

• セットアップのしやすさ
• ワークフローの設定（<->コードレビュー->テスト->トランク、次にトランク->統合テストブランチ->リリースブランチにバグ修正を加えたリリース）、監査（バグが導入されたときに発見された）
• メトリックの生成
• ClearCaseに慣れている開発者にとっての合理的な学習曲線。
• Windows開発
• 課題追跡システムの統合（石に設定されていませんが、おそらくRedmineになるでしょう）

私はすでにこれに対する答えを知っていると思いますが、とにかく尋ねると思いました：

機密情報を含むファイルが Mercurial リポジトリに追加されました。リポジトリ全体を削除せずに、変更履歴とともにそのファイルを削除する方法はありますか?

ドキュメントには次のように記載されています。

どれどれ：

git show は、409c.. と 533e の同じ変更セットを示しています

これは、変更セットが master と release-1.1.0 の両方にあることを意味します。では、どうして git cherry が 533e.. を表示するのでしょうか?

git サブモジュールを使用する場合、カスタマイズを行うための推奨される方法は何ですか? するべきか...

• プロジェクトをフォークし、フォークを追跡する
• デフォルトの動作をオーバーライドしようとする
• ローカルで変更を加える

これらのどれも意味をなさない場合、何が意味するのでしょうか?