9

私は SVN ショップで働いていますが、仕事に少し正気を吹き込むために git-svn を使用しています。ますます多くの同僚が光を見ています。そして今、場合によっては SVN を完全に回避したいと考えています。現在、私たちはそれぞれ独自の git-svn リポジトリを持っていますが、ハッシュが大きく異なるため、単純なパッチまたは SVN 経由以外は何も共有できません。(git-remote を介して) 直接共有できるようにするには、リポジトリをどのように編成すればよいでしょうか?

私が思いつく唯一の方法は、SVN へのゲートウェイとして使用する単一の共有 git-svn リポジトリです。独自の git-svn リポジトリから直接 SVN にプッシュできます。

編集:残念ながら、私は SVN サーバーへの管理者アクセス権を持っていません。

4

5 に答える 5

7

subgitを見ることができます：

SubGit は、スムーズでストレスのない Svn から Git への移行のためのツールです。サーバー側に一度インストールすれば、Subversion と Git の両方を好きなだけ使用できます。

SubGit を使用すると、双方向の Subversion から Git へのレプリケーション (書き込み可能なミラー) をセットアップできます。

と：

SubGit は、次のような Svn から Git への全社的な移行のためのソリューションです。

Much better than git-svn (see comparison);
Requires no changes of the infrastructure that is already in place;
Allows one to use all Git and all Subversion features;
Provides genuine stress-free migration experience.
于 2013-03-07T10:05:40.313 に答える
1

私たち全員が自分の git-svn リポジトリから直接 SVN にプッシュできれば、はるかに良いでしょう。

何のgit svn dcommitためのコマンドではないでしょうか？

git svn rebasegit クローンを中央の svn リポジトリにリベースしてからgit svn dcommit、ローカル コミットを svn にプッシュするために使用します。

GCC git mirrorで git svn を毎日使用していますが、非常にうまく機能します。おそらくそれは、svn コミットから自動的に更新される中央の読み取り専用ミラーがあるためです。そのため、git-svn を使用するすべての人は、git ミラーと同じ一連のコミット ID から同じ履歴を見ることができます。これにより、読み取り専用ミラーからのフェッチとマージが可能になり、次に git svn rebase と git svn dcommit で変更を svn リポジトリにプッシュできます。これらの変更は、読み取り専用ミラーに同期され、同じ ID を持つ他のすべての人によって取得されます。

于 2013-03-07T10:14:45.207 に答える
1

私たちはまったく同じ状況にあります。私たちが持っているのは（警告、いくつかの疑似コードです！）：

  • リモート git リポジトリ、スクリプト化 (bash スクリプトを使用)、 --bare にすることはできません

  • ユーザー名をチェックする pre-receive フック、次に受信した各参照ごと、およびすべての SVN マップブランチに対して: (git -> svn):

    • git checkout -f <branch>
    • git reset HEAD --hard
    • git clean -fdx
    • git merge -n $newrev
    • git svn dcommit

    • 失敗した場合はすべて元に戻し、

    • 次に、すべてのループの後 - すべての SVN ブランチを更新します (スクリプトを使用、以下を参照)

  • 最新の svn 変更 (svn -> git) で git-svn ブランチを更新する cronjob:

    • git checkout --orphan svn-update <random-branch-name>
    • git svn fetch --all
    • すべての git-svn ブランチ: git branch -D <branch> && git branch --track <svn-branch> refs/remotes/<svn-branch>,

  • git 認証用の ssh キー

  • ユーザー管理の SVN 認証 (git ユーザー名に基づく。これはセットアップによって異なります)

この方法では誰も SVN を直接使用せず、純粋な git との唯一の違いは、git-svn ブランチの履歴を変更できないことです (SVN ではそれを dcommit できないため)。

于 2013-03-07T10:39:18.337 に答える
1

2 つの異なるバージョン管理システム間の双方向のゲートウェイ機能は、git よりもずっと前から存在します。10 年ほど前に、CVS と Arch の間ですでに手動で行っています。subgit を購入したくない場合は、ゲートウェイを手動で維持するか、スクリプトを作成することもできます。ワークフローは簡単です。

  • 2 つのブランチを持ち、trunkとmaster. trunkサブバージョンをミラーリングmasterし、git で開発された変更を加えたものです
  • サブバージョンに新しい変更があるときはいつでも:
    1. $ git svn fetch
    2. master$ git merge trunk
  • トランクが押されるたびに:
    1. trunk$ git merge master
    2. trunk$ git svn dcommit
    3. master$ git merge trunk
  • 両方のシーケンスをアトミックに実行する必要があります。つまり、一度に 1 つの操作だけです。
  • gitでのマージ コミットの数を減らすために、コミットを Subversion リビジョン情報で書き換えないように git-svn を設定することを検討してください。
  • 複数のブランチに対して実行できますが、git で個別のサブバージョン ブランチをマージすることはできないと思います。
于 2013-03-07T10:33:09.247 に答える
1

私は似たような環境にいます。私と一緒に働いている人たちのために働いたプロセスは次のとおりです。

  1. 1 人は、友人を使用して Git リポジトリを作成しますgit svn clone。

  2. 他のすべての人は、通常の Git コマンドを使用して最初の Git リポジトリのクローンを作成しsvn-remote.{name}、最初のリポジトリの一部をコピーします.git/config。の例に、これを行うための手順がありgit help svnます。

これで、誰もがgit-svnSubversion リポジトリとやり取りするために使用できるセットアップを完了しました。

さらに重要なことは、誰もがgit-svn同じブランチとコミット履歴を持つセットアップを持っているということです。つまりgit svn fetch、友人が作成したコミットはハッシュを含めて同一になります。その時点で、Subversion リポジトリへのプッシュとプルだけでなく、Git のより洗練された分散機能をすべて使用できます。

通常の Git とは異なり、構成の共有には注意が必要です。ブランチ構造が分岐すると、ハッシュも分岐します。時折、問題が発生し、修正が必要になります (私は一度に 2 つのgit svn fetches を実行していたことがあり、それがお互いの作業を微妙な方法で破壊していました。git svn reset自分のハッシュを他の人のハッシュと一致させるために、履歴を巻き戻し、再フェッチする必要がありました)。しかし、それらは 2 つのツールを一緒にマッシュアップする際の制限です。

于 2013-03-07T16:53:43.193 に答える