0

議論のために、私が Y という依存関係を持つプロジェクト X に取り組んでいるとしましょう。現在、Y はサード パーティによって定期的に維持および更新されているスタンドアロンのオープン ソース プロジェクトです。Y の最新リビジョンをチェックアウトし、それを X をホストするリポジトリにコミットします。時間が経つにつれて、ローカル リポジトリで Y に変更を加える可能性があります。2 か月後、最新のバグ修正や機能などを取得するために、オープン ソース リポジトリからの最新の変更を自分のリポジトリにマージすることにしました。これら 2 つのブランチが同じリポジトリの一部であった場合、これは簡単なことではありませんでした。 . Git、Mercurial、および Subversion でこのクロスレポ マージを [比較的] 簡単に行うにはどうすればよいですか?

ありがとう。

4

2 に答える 2

2

Y のコピーを X のリポジトリに入れると言っているのですか? もしそうなら、それはあなたが言及したVCSのいずれかに対してそれを行う正しい方法ではありません. Y のリポジトリを Y-mine に「フォーク」して、変更をコミットします。次に、プロジェクト X のビルド システムの構成ファイルに、リポジトリ Y-mine 内の特定のリビジョンへのポインターを依存関係として含めるようにします。最新のビルド システムはこれを行います。

これにより、両方の長所が得られます。必要なときにいつでも Y から Y-mine にマージでき、100% 再現可能なビルドのために正確なバージョンの Y-mine を X に格納できます。

Git と Mercurial にはどちらも、「バージョン Z の Y-mine はレポ X の一部です」と言うことができるサブレポ システムがありますが、pip、ma​​ven、sbt、gem、visual studio、ivy2 などを許可するよりも扱いにくいです...依存関係の管理を処理します。

于 2013-04-30T04:08:18.673 に答える
1

My take on that is that you could look at what Debian does with its Git packaging workflow employing the git-buildpackage tool.

The workflow provided by this tool is agnostic with regard to VCS used by upstream vendor, and is organized (roughly) like this:

  • You have (at least) two branches: upstream and master.

  • upstream holds snapshots of (unmodified) upstream sources usually taken from release tarballs provided by the upstream vendor. That is, each commit on this branch results from these steps:

    1. The upstream branch is checked out.
    2. All existing files are deleted (git rm -rf .).
    3. The new version of upstream sources is unwrapped and copied over to the work tree, and then added (git add .).
    4. A new commit is then recorded (and a tag upstream/vX.Y.Z is created pointing to this commit).

  • master contains what's on upstream plus a set of files providing the infrastructure to build the Debian package (actually, this is just a single directory named "debian").

    Each time a new version of upstream sources is imported to the upstream branch, that branch is merged into master, and the package maintainer then works on master tailoring their "debianization" to match the changes introduced by upstream.

I think this approach might well be used in your case using plain Git:

  • Maintain such an "upstream" branch (you might call it "vendor" or "that_framework" etc). It should receive only new versions of upstream sources (and may be also occasional upstream patches etc).
  • After importing the new versions of upstream sources to that branch merge it to your master (or whatever branch suits better in your workflow).

Working with Mercurial and Subversion could also be done using their respective Git shims, but I suspect (while not being exactly sure) that this would rather complicate matters, not simplify.

于 2013-04-30T14:55:07.603 に答える