14

チームを CVS から遠ざけるためのさまざまなオプションを検討しています。Subversion を使用する別のサイトに別の大規模なチームがあり、一部の開発者は Subversion サーバーで作業しています。したがって、Subversion は私たちのチームにとって当然の選択です。でも：

  1. Subversion サーバーが関与する操作は、コーヒーブレイクのように遅くなる可能性があります (ただし、サイト間の接続は良好です)。
  2. 私たちの多くは、分散バージョン管理のアイデアを支持し、Mercurial や git を広く使用しています (そして、マージして CVS にコミットし、変更を取得します)。

git-svnは面白そうに見えますが、私が知りたいのは、Subversion に一握りの集中ブランチがあると、git などの DVCS のパワーがどれだけ失われるかということです。特に、次のような Mercurial でのワークフローを維持できるようにしたいと考えています。

  1. Subversion のメインの安定したトランクに移動する前に、他のチーム メンバーのリポジトリをプルしてマージし、フィーチャー ブランチで共同作業することはできますか?
  2. git で可能な豊富な策略が一般的に機能することを期待できますか、それとも git-svn を混乱させないように注意する必要がありますか?
  3. git を使用して Subversion からのチェックアウトを高速化するには、接続を介して他のサイトから 1 回プルしてから、個々のリポジトリに 1 回プルする必要があります。
  4. 誰かが Subversion にコミットした場合、git-svn を介して他の git ユーザーが完全な開発履歴を見ることができるように手配できますか?
  5. 半世界のレイテンシがあるにもかかわらず、Subversion サーバーでインタラクティブな操作を待つ必要を基本的に回避できますか?

私たちの多くは、誰もがプッシュできる単純な線形履歴を持つ、かなり安定した主要な共有ブランチのアイデアに慣れているため、定期的に先端にマージします。このワークフローを git (または Mercurial や Bazaar) でうまくサポートする方法がよくわかりません。

4

3 に答える 3

2

あなたは多くを失い、二流のように感じますが、すべての素晴らしい分岐要素を得ることができます.

Subversion でホストされているプロジェクトで作業するために git を使用して、git を学びました。git のおかげで、メインストリーム ブランチを追跡したり、自分の作業を他のユーザーと共有したりしながら、すべてのローカル開発を行い、プロジェクトでかなりの進歩を遂げることができました。

最終的に、プロジェクト全体を git にプッシュすることになりました。これは、subversion に移行したときにすべての情報が失われたためです。

失うもの:

  1. マージ追跡 - 一種。
  2. 変更の作成者の適切な記録。

私が「一種の」WRT #1 と言うのは、1 つのツリーをまとめておくと、git で行って subversion に適用したマージやものを追跡するためですが、そのレポを複製しようとしたり、他の誰かが git を実行したりすると、 -svn クローンを作成すると、それが失われ、マージが再び非常に苦痛になります。

私にとって、著作者であることは非常に重要です。なぜなら、人々が自分の仕事に対して功績を認められるようにすることが非常に重要だからです。

于 2009-02-12T19:51:44.793 に答える
2

すでに述べたように、純粋なGit エクスペリエンスgit-svnと比較して特定の制限があります。

  1. チームのコラボレーションは難しい:

    ある開発者が SVN リポジトリに変更をプッシュするとgit-svn、別の開発者はわずかに異なる変更をフェッチします。フェッチされたコミットは、Git から SVN に、SVN から Git に 2 回変換されました。その結果、分散した方法でコラボレーションすることは困難です。

  2. 失われたメタデータ:

    git-svn変更を SVNに送信すると、.gitignore および .gitattributes ファイルが失われgit-svnます。つまり、そのメタデータが対応する Subversion プロパティに変換されません。他の開発者は、フェッチ時にメタデータの変更を受け取りません。

  3. 失われたマージ追跡データ:

    2 つのブランチを でマージしてから でgitマージ コミットをプッシュするとgit-svn、Subversion リポジトリはマージされた履歴に関するデータを自動的に取得しません。

  4. 弱い分岐のサポート:

    Subversion リポジトリでブランチを作成し、それを取得してgit-svnから、このブランチへの変更を dcommit する必要があります。通常の Git ブランチを作成し、それを SVN リポジトリにプッシュバックしようとするとgit-svn、新しいブランチは作成されず、代わりに既存のブランチにコミットが送信されます。

SubGitgit-svnは、次の機能を備えた代替手段です。

  • SubGit はサーバー側で一連のフックとして機能し、SVN と Git リポジトリを同期して、両側を書き込み可能に保ちます。

  • SubGit 対応の Git リポジトリを操作するために、任意の Git クライアントを使用できます。すべての Git ワークフローがサポートされています。

  • SubGit は、git-svn上記の問題をすべて修正します。

SubGit は、多くの無料オプションを備えた商用ソフトウェアです。詳細については、ドキュメントとgit-svn との比較を参照してください。

免責事項: 私は SubGit 開発者の 1 人です。

于 2013-02-20T20:38:55.583 に答える
1

私が見た限りでは、git-svn を使用してリポジトリ取得の間に git を使用できます (そのため、話している svn リポジトリの「ミラー」となる git パブリック リポジトリを持つことができますが、git リポジトリはあなたのサイトでホストされています）。

したがって、git ユーザーのチェックアウト/クローン/プッシュ/プルは高速になります。次に、git リポジトリにフックを追加して、git-svn 経由で svn リポジトリと同期できると思いますが、別のブランチを使用するまで競合に対処する必要があります。

ここで行うことは、すべての開発者には自分の名前が含まれるブランチがあり、管理者がブランチをマスターとマージする前にマスター ブランチとマージする必要がある (競合を処理する) ことです。開発者は既にそれを処理しているため、競合は発生しません。 .

この助けを願っています。

于 2009-02-12T11:04:36.823 に答える