問題タブ [git-svn]

リポジトリ全体のgit-svnチェックアウトがあります（標準的な方法で初期化されてgit svn init -t tags -b branches -T trunk $repo_urlから、git svn fetchedになります）。手動でsvn copy $repo_url/branches/branch1 $repo_url/branches/branch2。次に、を実行しgit svn fetch、git checkout -b local-branch2 branch2にいくつかのコミットを行いbranch2、dcommitそれらをSVNリポジトリに戻し、での作業を完了しましたbranch2。（なぜブランチをブランチするのですか？gitでローカルにこのブランチをハックしたかったのですが、それでもSVNにコミットして、作業中に数人の同僚から助けを得ました）。

私が行っていないのは、branch2作業をにマージして戻すことbranch1です。もし私がそうならgit checkout -b local-branch1 branch1、それは単に私のポインタをどこにあるかgit merge branch2へと早送りします。local-branch1branch2

代わりに、ブランチ1を開始してから行われたすべてのコミットをgitで再生して、各コミットをbranch2SVNリポジトリにコミットできるようにします。これを行う方法があるようですが、私はそれを考えることができません。たぶんgit rebase、またはgit cherry-pickで行われた各コミットのbranch2？（後者は少し退屈ですが）。2つのURLをsvnマージしたくないのは、それが大きな打撃となるからです。

アイデア？これのどの部分にももっと説明が必要ですか？

奇妙なレイアウトのSubversionリポジトリがあります：

トランク

タグ

枝

私は知っています、私は知っています、これは愚かでした。各プロジェクトの下にトランク、タグ、ブランチディレクトリが必要でした。しかし、これを履歴付きのgit（特定のプロジェクト用）に変換する方法はありますか？

ほとんどのgit-svnチュートリアルは標準レイアウトを想定しており、この特定の状況については説明していません。

ありがとう！

現在、次のワークフローで git-svn を使用しています

その後、私が機能に取り組むとき

ここで、機能をマスターに git マージする際のいくつかの注意点があります。

コミット メッセージは「merged with featureZ」に置き換えられます。これはmerge fmt msgで修正できます。

ここで私の質問は、このワークフローで問題が発生する可能性があること、または対処する必要があることはありますか? git svn を使用する場合はマージを行うべきではないというgit-svn のマニュアルを読みました。私がワークフローで行っていることは、彼らが言及していることですか? もしそうなら、それはどのような問題を引き起こしますか？1 つのことは、SVN のメインラインを台無しにするようなことはしたくないということです。

Subversion リポジトリでブランチが見つかると、git svn fetch が同じ Subversion リビジョンを繰り返し取得するのを見ています。最上位の /trunk、/tags、および /branches ディレクトリを持つ標準の Subversion リポジトリ レイアウトを使用しています (そして、git リポジトリは 'git svn init -s' で作成されました)。ただし、問題のあるブランチは、トランクではなく、トランク内のサブディレクトリから作成されたコピーであることがよくあります。

git svn fetch の出力は通常、次のようになります。

そして、リビジョン 1 に戻ります。git svn fetch は、ブランチを作成したリビジョンに到達するまでリビジョンをフェッチし続けます。

私は何を間違っていますか？git svn fetch に、すでにプルされたリビジョンを取得しないように指示する方法はありますか?

この質問はこれとこれに似ていますが、シナリオは少し複雑です。

私は数年前にプライベートsvnリポジトリ（主にさまざまなマシン間で共有される設定ファイルなどに使用します）から始めました。リポジトリのレイアウト（ブランチ、移動など）にはあまり注意を払っていなかったので、時間の経過とともにかなり変化しました。もちろん、これは間違いでしたが、今では手遅れです。最近、私はそれをより標準的なsvn trunk / branchs / tagsレイアウトに移行しましたが、主にsvn moveコマンドを使用していますが、もちろん古い履歴はリポジトリに残っています（率直に言って、少し混乱しています） 。

これを永続的にgitリポジトリに変換したいと思います。git-svnを使用してみましたが、一貫したトランク/ブランチ/タグの規則に従っている状況のみを処理しているようです（はい、代替名を指定できますが、それぞれに1つしか表示されません）。私のリポジトリの履歴のかなりの部分は、たとえば、サブディレクトリとしてtags/とbranchs/を使用して、リポジトリのルートに効果的にトランクを持っています。

これらすべてを処理するための最良の方法は何ですか？理想的には、ブランチとタグがgitでファーストクラスの概念として適切に表現されていない場合でも、最終的にgitリポジトリに何らかの方法ですべての履歴にアクセスできるようにしたいと思います。

より具体的には、svn-gitは、提供されているトランク/ブランチ/タグサブディレクトリ外のファイルをどのように処理しますか？これまでの私の観察では、それらを見逃すことがあり（間違いなくOKではない）、新しいリポジトリに追加することもあります。

どんな考えでもいただければ幸いです。

git-svn を使用して svn ブランチを作成しようとしています。リポジトリは で作成されました--stdlayout。残念ながら、「ソースと宛先が同じリポジトリにないようです」というエラーが生成されます。エラーは、ソース URL にユーザー名が含まれていないことが原因のようです。

$ git svn branch foo-as-bar -m "Foo を Bar にしようとしています。"

r1173 の svn+ssh://my.foo.company/r/sandbox/foo/trunk を svn+ssh://svnuser@my.foo.company/r/sandbox/foo/branches/foo-as-bar にコピーする...

サポートされていない機能を使用しようとしています: ソースと宛先が同じリポジトリにないようです (src: ' svn+ssh://my.foo.company /r/sandbox/foo/trunk'; dst: ' svn+ssh: //svnuser@my.foo.company /r/sandbox/foo/branches/foo-as-bar') at /home/me/.install/git/libexec/git-core/git-svn 行 610

私は当初、これは単なる設定の問題だと思って.git/configいました。

を使用してgit version 1.6.3.3います。

なぜこれが起こっているのか、そしてそれに対処する最善の方法について誰かが光を当てることができますか?

数週間前にGitでYouTubeプレゼンテーションTechTalk：Linus Torvaldsを見ましたが、1つの発言が頭に残っているようです。

このプレゼンテーション（約33分）で、Linusは、「一部の人々はSVNリポジトリのクローンを作成し、マージ（= SVNでの頭痛）を行ってから、結果をSVNにプッシュバックします」と述べています。

私が持っている考えは次のとおりです。これが可能であれば、GITの優れたマージ機能を移植してSVNの不可欠な部分にしないのはなぜですか？

これにより、SVNが大幅に強化され、あらゆる種類の問題追跡システムや継続的インテグレーションシステムに接続する企業リポジトリや関連スクリプトを移行する必要がなくなります。

私は何かを逃したに違いない。それは何ですか？

2 つの SVN リポジトリに存在するプロジェクトがあります。2 番目の SVN リポジトリは、SCM 情報を削除せずに、古い SVN リポジトリのチェックアウトからリポジトリを追加するだけで作成されました。ファイルの内容はバイト単位で同一ですが、関連する SCM メタデータはありません。

新しい SVN リポジトリを取得し、git-svn を介して Git リポジトリに移植しました。ここで、古いリポジトリをインポートし、新しいリポジトリにリンクして、両方の履歴を確認できるようにしたいと考えています。2 つのリポジトリを手でつなぎ合わせずにこれを行う簡単な方法はありますか?

Git-svn では、大文字と小文字が異なるだけで重複するファイル名が許可され、Subversion リポジトリに追加されました。

Windows では、これは Subversion がファイルをチェックアウトできず、重複していると訴えたことを意味していました。

別の開発者が、大文字と小文字が正しくないバージョンをリポジトリから削除しました。git-svn rebase を実行しようとすると、「HEAD をデタッチできませんでした」というメッセージが表示され、問題のファイル名が追跡されておらず、上書きする必要があるという苦情が表示されます。ファイルを削除すると、git-svn はファイルを更新する必要があると文句を言います。

大文字と小文字を区別するファイルシステムを持つマシンにリポジトリをコピーする唯一の解決策は、リベースを実行してから元に戻すことですか?

git-svn が Windows で実際に動作する準備ができていないことは理解していますが、git-svn が作成したこの混乱から回復したいと考えています。