Gitリポジトリ内でSubversionリポジトリを使用する方法

私はGitでプロジェクトを開発しています。ITはSubversionリポジトリにある別のプロジェクトに依存しています。ツリー内のSubversionプロジェクトに変更を加え、Gitプロジェクト内からSubversionリポジトリにコミット/更新できるようにしたいと思います。それは可能ですか？

Xzibitのネストされたアイテムのミームを考えるのは私だけではありませんか？とにかく...

Subversionが行う残りのクールな機能の1つは「外部」と呼ばれます。これは、別のsvnリポジトリ内の特定のブランチまたはディレクトリを指す方法です。特定のディレクトリの特定のバージョンにピン留めすることもできます。外部は本当に気の利いたものであり、外部ディレクトリで行われた変更はコミットを実行すると自動的にソースにプッシュバックされるため、この問題はすぐに解決されます。

外観もgitに欠けています。Gitにはサブモジュールがありますが、特定のコミットに関連付けられているため、同じように機能しません。これは事実上、同時に読み書きが可能で完全に同期した「ネストされた」リポジトリの問題に対するネイティブの解決策はなく、異なるバックエンドを使用したネストされたリポジトリも同様に存在しないことを意味します。

サブモジュールリビジョンのピン留めダンスを実行したくない場合は、別の回避策があります。

Gitは、git-svnツールでまともなsvnエミュレーションを備えています。おそらくすでに使用しています。SOの質問「git-svnを使用してsvn：externalを最新の状態に保つにはどうすればよいですか？」そのツールを悪用することで私たちに便利なオプションを提供します。

受け入れられた答えは、単にgitによって制御されているツリーの外でgit-svn Subversionリポジトリをチェックアウトするために使用し、シンボリックリンクを使用してツリー内を指し示すだけでした。リポジトリを変更するたびに特定のリポジトリをコミットすることを覚えておく必要があるため、これには少し手作業が必要です。ただし、それは単純で、簡単で、動作することが知られています。

別のオプションは完全に Mercurialのを見ていることでしょうsubrepositoriesのgitとSVNの両方をホストすることができ、。あなたが本当に3つのレベルに行きたいかどうかはわかりません。

Charlesには勧められませんが、あなたは本当にgit サブモジュールを探していると思います：

Gitのサブモジュールサポートにより、リポジトリにサブプロジェクトとして外部プロジェクトのチェックアウトを含めることができます。サブモジュールは独自のIDを維持します。サブモジュールのサポートはサブモジュールリポジトリの場所とコミットIDを格納するだけなので、含まれているプロジェクト（「スーパープロジェクト」）を複製する他の開発者は、同じリビジョンのすべてのサブモジュールを簡単に複製できます。スーパープロジェクトの部分的なチェックアウトが可能です。Gitにサブモジュールをクローンしないように指示することができます。

Charlesは、git サブモジュールはsvn 外部のように機能できない（特定のリビジョンではなくブランチのヘッドを参照する）ために不十分であると考えているようですが、これは期待されるワークフローgitとsvn他のワークフローの違いが原因であると思います。

作業コピーをいつ、どこで更新したかによって、svn作業ディレクトリ階層の異なるポイントにあるディレクトリは、異なるリビジョンになる場合があります。これは、では不可能gitです。ではgit、あなたが前回とまったく同じコードを取得することリビジョン123ABCに行くとき、あなたが123ABCをチェックアウトすることを期待し、それが含まれています-あなたがリビジョンに更新するたび、あなたはそのリビジョンに作業コピーの全体を更新するいかなるリビジョンに含まれる可能性のあるすべてのサブモジュール。

サブモジュールを更新する場合は、サブモジュールを更新してから、スーパーモジュールに新しいコミットを作成して、サブモジュールの新しいリビジョンを使用するように更新する必要があります。これは、サブモジュールは外部よりも柔軟性が低いことを意味gitしますが、リポジトリ全体のスナップショットの主要なパラダイムを適用します。

svn 外部が常に最新のリビジョン機能を使用するようにしたい場合は、ほとんど自分で行います。前述のように、svn サブモジュールを手動でチェックアウトしてから、それをチェックアウトするだけ.gitignoreです。

• svn動作の仕方を考えると、外観の動作は完全に許容できます。
• git動作の仕方を考えると、サブモジュールの動作は完全に許容できます。

ちなみに、これまで私はそれを理解し、Mercurialのようsubrepositories Gitのと同じように仕事のサブモジュール、それはどちらかの助けにはなりませんので。

あなただけを探していgit-svnますか？場合によっては、親バージョンがsvnにあるということですか、それともsvnプロジェクトであるベンダーがあるということですか？

依存と仮定すると、依存を意味します。

問題なくgitリポジトリ内に任意の種類のリポジトリを置くことができます。例えば

$ mkdir ~/project
$ cd ~/project
$ git init
$ ...
$ git commit -va
[master (root-commit) xxxxxxx] Did something
 ...
$ mkdir vendors
$ cd vendors
$ svn checkout svnproject(url)
$ cd svnproject
$ ...
$ svn ci -m "committing to svnproject"

等

その後、svnproject通常どおりに管理します。もちろん、git-svn代わりにgitコマンドを使用してsvn repoとやり取りすることもできます。

これを行うこともできます：

$ cd ~/projects
$ git add vendors/svnproject
$ git commit -m "adding svnproject source to main repo"

その場合、ファイルに加えた更新svnprojectはsvnとgitの両方の差分として表示されます。例/tmp/gitproject.. gitのプロジェクトであり、および/tmp/gitproject/vendor/minify（ランダム）SVNのチェックアウトです。

[andy@laptop:/tmp/gitproject/vendor/minify]$ vim README.txt 
[andy@laptop:/tmp/gitproject/vendor/minify]$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working     directory)
#
#   modified:   README.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
[andy@laptop:/tmp/so/vendor/minify]$ svn status
M       README.txt
[andy@laptop:/tmp/so/vendor/minify]$

を使用git-svnしてsvn依存のリポジトリとやり取りする場合、それを使用して親gitプロジェクトで行った変更と同期を保つことができるためgit-filter-branch、各リポジトリに個別にコミットする必要はありません。

余談ですが、gitとsvnプロジェクトの同期を維持する経験から、どちらかが読み取り専用でない限り、一般にかなり問題があります。

Gitにはsvnラッパーがあります。ここに簡単な要約があります：SubversionでGitを効果的に使用する

Railsを使用している多くの組織と同様に、私たちはgitの波に乗っており、gitとSubversionの間の移行期にあります。私たちのオープンソースの作業はgitリポジトリに保存されていますが、クライアントの作業はまだSubversionリポジトリに保存されており、おそらくしばらくはそうでしょう。gitは素晴らしいですが、Subversionは依然として優れた品質を備えており、特にユーザーフレンドリーなツールのエコシステムを備えた優れた集中型リポジトリを作成します。

gitとSubversion（git-svn）の統合は非常にうまく行われているため、私たちの何人かはすべてのSubversionリポジトリへのインターフェースとしてgitを使用しています。これを行うのはかなり簡単ですが、興味深いトリックがいくつかあるので、Vigetの人生の1日をgit-svnと共有すると思いました...