現在、次のレイアウトのSubversionリポジトリがあります。
これはかなり悪いレイアウトだと思いますが、現時点では完全に変更することは困難です。
個人的には、履歴の確認に時間がかかることや、分岐やマージが面倒なことなどから、Subversionが嫌いなので、代わりにgitを使いたいと思っています。
残念ながら、一部の人の精神的能力が圧倒される可能性があるため、gitに切り替えることはできません。そこで、問題を解決するために実際にそれを使用できるかどうかを確認するためにgit-svnを調べていました。
残念ながら、各プロジェクトを1つのgitリポジトリに分割したいので、それは直接悪い状況になります。また、作業している各コンピューターでgit-svnチェックアウトを再作成する必要はありません。だから私はおそらくある種の透過的なgit←→svnプロキシ/ゲートウェイを作成する可能性があるので、そのリポジトリへのプッシュはsvnリポジトリに「コミット」し、svnリポジトリへのコミットはgitリポジトリを更新します。
Googleは私の友達ではなく、git-svnを使用するための一般的な使用法のヘルプしか見つけていないので、これを達成するための良いアイデアがあればお願いします。
透過的なGit/Svnゲートウェイの場合、 SubGit を使用できます。ただし、現時点では、単純な単一プロジェクト(/ trunk、/ branchs、/ tags)または複数のプロジェクトのみをサポートしている点が異なります。プロジェクト(/ project/trunk、...)レイアウト。
Subversionサーバーを制御しない、または混乱させたくない場合は、SubGitを使用できません。この場合にできることは、トランクごとに自動的に同期されたgitリポジトリを用意することです。私たちのチームはこのように機能します-私たちのチームのgitリポジトリと企業のSubversionリポジトリ内のプロジェクトのトランクの間の変更を同期するgit-Subversionブリッジがあり、gitの使用が他のSubversionユーザーに対して透過的です。
セットアップの詳細については、 https://github.com/mrts/git-svn-bridge を参照してください。
このセットアップは、1年以上本番環境で使用されています。
セットアップの最大の注意点は、トランクへのマージ中にgitブランチが1つのコミットに押しつぶされることだと思います。私たちにとってこれは問題ではありません-短命のタスクブランチを使用し、それらを軽量で一時的な「作業単位」と見なし、単一のチャンクでメインラインに移動できます-ブランチ履歴はgitに保持されます。
基本的に2つのオプションがあります。
クライアント側でgit-svnを許可して問題を解決します。最初のチェックアウトにはしばらく時間がかかりますが、ネイティブのsvnチェックアウトと同じ機能(git svn dcommit
とgit svn [fetch|rebase]
のプッシュとプルを含む)をすべて提供できます。--stdlayout
でクローンを作成すると、完全な分岐とタグ付けがサポートされます。 (私は私の会社でこれを行っています。私はsvnサーバーでgitを使用している2人の従業員のうちの1人であり、問題はありません。)
Git-svnを使用してリポジトリを別のサーバー(または同じサーバー)に複製し、そのリポジトリからgitのホスティングを開始します。次に、以前のすべてのsvnデータを含むネイティブのgitリポジトリがあります。
各コンピューターで「gitsvnclone」を実行したくない場合は、次のことができます。