3

以前にも関連する質問が寄せられましたが、2 つのソース コントロール管理 (SCM) システム間の相互運用性を実現する方法についてのアイデアを知りたいと思います。たとえば、あらゆる SCM (Mercurial、Git、SVN、CVS、Perforce、ClearCase など) を考慮することができます。

主に、ClearCase を SVN や Git/Mercurial と併用できるかどうかに関心があります。

リモートの ClearCase で管理されているソース ツリーを別の SCM (ClearCase 以外) で管理するにはどうすればよいですか?

他の人は ClearCase を使用できますが、「他の」SCM を使用して、そのリポジトリで変更をコミットしたいと考えています。ClearCase リポジトリの変更は、すぐにまたは定期的に行う必要があります (また、ClearCase リポジトリからの更新は、最新のソースがあることを確認するために定期的に行う必要があります)。

（その他/関連する）例/経験は大歓迎です。ありがとう ！

PS: これはClearCase をダンプすることではなく(喜んでそうします)、同じソース ツリーで同時に 2 つのソース管理を操作することです。

4

6 に答える 6

4

それらを混ぜないことを本当にお勧めします。1 つの SCM を管理することは非常に複雑なタスクであるため、通常のユーザーが複数の SCM を処理する必要はありません。

それでもミックスしたい場合は、Mercurial や git などの分散型 SCM には、誰にも押し付けずに使用できる優れた機能があります。各開発者/チームは、自分のローカル コピー/ローカル ブランチを git または mercurial で誰にも気付かれることなく管理できます。

git + subversion または mercurial + subversion には、メイン リポジトリへのプッシュ バックがツールの一部であるという利点がありますが、それがなくても問題ありません。

あなたの場合、ClearCase が強制されているように見えますが、別の方法を使用したいと考えています。チームで git を使用することを決定し、メイン ブランチを定期的に ClearCase にプッシュすることができます。

于 2009-01-16T15:34:10.990 に答える
1

私の頭に浮かぶのはgit-svnです。「これは、Subversion と git リポジトリの間で双方向の変更の流れを提供します。」

于 2009-01-16T15:16:33.553 に答える
1

他の SCM に ( .cvsignore/.hgignoreのようなファイルを介して) 相互に無視させるか、(のようにgit svn) 協力させることができる限り、それを行うことができない理由がわかりません。私はすでにsvn/Hg/gitとCVSを使っています。

于 2009-01-16T15:17:41.177 に答える
1

非常に一般的な方法で、「外部」(あなたの場合は ClearCase) リポジトリの現在の HEAD を常に git ブランチにコミットし、その上に独自のブランチをリベースして、結果を「外部」リポジトリにコミットすることができます。泡立てて、すすぎ、繰り返します。

于 2009-01-16T15:30:49.780 に答える
1

2 つのソース管理管理 (SCM) 間の相互運用性の問題は、一方の SCM が他方よりも豊富なモデルを持っている場合です (たとえば、1.5.0 より前の Subversion は、svnmerge または SVK を使用しなかった場合、マージのすべての親を保存しませんでした。最近のほとんどの SCM はマージを覚えていますが、Mercurial はタコのマージ、つまり 2 つ以上の親とのマージをサポートしていません)。

私が知っている少なくともいくつかの異なる種類のソリューションがあります。

  • Git で作成されたが Bazaar でサポートされているが、Mercurial や Tailor などのツールでもサポートされている高速インポート交換標準のような汎用SCM 相互運用性ソリューション(ただし、Tailor には制限があります)
  • Git と Subversion 間の git-svn (Subversion Perl API を使用) や Git と Perforce 間の git-p4 など、SCM API または SCM スクリプト機能のいずれかを使用する特定のツール
  • つまり、共通の作業領域 (作業ディレクトリ) を使用して、1 つの SCM から変更を取得 (チェックアウト) し、他の SCM に変更を追加 (コミット) します。これには、適切な無視ファイルを設定する必要があるため、1 つの SCM が他の SCM 固有のヘルパー ファイルとディレクトリを無視します。
  • 集中型 SCM (CVS など) と他の SCM (Git など) の間の相互作用の場合のサーバー エミュレーション。
  • 1 つの SCM (Bazaar や Darcs など) が変更 (データ) を他の SCM 形式のリポジトリに格納するデータ バックエンド。私はそのような解決策の例を知りません。
于 2009-01-16T15:44:25.993 に答える
0

私はBlueBird75に同意します。2つの異なる参照を混合することは良い考えではありません。同じ理由で、同じ種類の情報を持つ複数のデータベースを持つことは良い考えではありません。このような場合、同期と複製を管理するのは簡単ではありません。

ClearCaseを使用しない他のチームの場合、ClearCaseリポジトリ（VOB）で管理されている一部のデータを他のVCS（Subversion、Perforceなど）またはリポジトリ（Mavenなど）に「公開」します。ただし、エクスポートされるデータは配信のみです。

「配信ユニット」は、パッケージ化されたファイルの小さな（可能な限り少ない数のファイルのように「小さな」）セットです。jar、war、earはすべて、そのようなパッケージ化されたファイルの例ですが、ソースも含まれています（ zipファイル）、javadoc（圧縮も）、この配信を実行するためのスクリプトなど。

このように、少数のファイルのみがクライアントにエクスポートされ、配信がビルドされて重要な安定バージョンを表す場合にのみエクスポートされます。

于 2009-01-16T15:56:48.447 に答える