問題タブ [vendor-branch]

以下で構成されるアプリケーションを開発しています。

• パートナーから頻繁に提供されないソースコードベース。これはやや機能するコードであり、何かの「最終」バージョンです（そして、zipファイルで取得します）。彼らは独自のリリースサイクルとバージョン追跡を持っています。
• 上記のコードベースで変更を加えます。これらは、バグ修正または新機能の開発のいずれかです。

今まで、私たちはなんとかコード騒乱を作成することができました。その結果、これらすべてをSVNリポジトリーに入れたいと思います。これをより少ない痛みで実現するためのベストプラクティスは何だと思いますか。

以下は、私たちが重要と考えるものです。

• ソフトウェアベンダーにバグ修正を返送することはできないため、バグ修正/変更を追跡したいと思いますが、バグを報告することはできます（修正される場合とされない場合があります）。私たちが彼らのコードで開発するものはすべて「社内」のままであり、彼らは私たちの変更に興味がありません。
• ベンダーから新しいコードベースを入手しない限り、最新バージョンは私たちが取り組んでいる安定したバージョンであると考えています。これはさらに分岐する可能性がありますが、結果は常に安定したトランクになり、ビルドはこの「安定した」トランクに基づいて行われます。
• ベンダーが新しいバージョンをリリースしたら、「安定した」トランク（多くの変更が含まれています）を変更とマージして、新しい「安定した」トランクを作成します。
• （クライアントに）デプロイするバージョンごとに、その特定のバージョンを使用してシステムをインストールしたクライアントについては、後でそのバージョンでのみバグを修正できるはずです。
• コードベースに取り組んでいる開発者はもっといます...（いつものように:)

ヒントをありがとう。

svnベンダーブランチを使用してサードパーティライブラリをアップグレードしようとしています。（ソースコードを変更しました）

すべての手順に従ってベンダーブランチを作成しました::

古いバージョン（サードパーティライブラリ）のベンダーブランチを作成しました最新バージョン（サードパーティライブラリ）のベンダーブランチを作成しました（usign svn_load_dirs.plスクリプト）を使用して最新バージョンを現在のフォルダにコピーしました

svnのベンダーリポジトリの構造

URL/ベンダー/ライブラリ/3.5.0URL/ベンダー/ライブラリ/3.7.0URL/ベンダー/ライブラリ/現在

私はライブラリを持っています-3.5.0はURL/トランク/ライブラリ/customized-libraryで使用/変更されています

URL/ベンダー/ライブラリ/3.7.0とURL/ベンダー/ライブラリ/3.5.0の違いをURL/トランク/ライブラリ/customized-libraryにマージしようとすると問題が発生します

URL / trunk / library / customized-libraryがチェックアウトされているフォルダーにいて、次のコマンドを使用してマージを実行します

svn merge URL / vendor / library / 3.5.0 URL / vendor / library/current。-パラメータを受け入れる

受け入れパラメータにtheirs-conflictを使用すると、古いバージョンへのすべての変更が無視され、mine-conflictを使用すると3.7.0からファイルがコピーされ、延期を使用すると3.7.0のファイルが無視され、例外がスローされます。 「ツリーの競合」

ありがとうギャン

リポジトリにMagentoEnterpriseEditionをインストールしていて、クライアントのサイトが実行されています。すべて問題ありません。このクライアントを新しいバージョンのMagentoにアップグレードしたいのですが、EEがアップグレードのために提供してくれる唯一の助けは、app/code/coreディレクトリ全体を削除して新しいファイルをに移動することです。

これは、控えめに言っても、最適ではありません。

SVNの履歴をきれいに保存しながら、どのように変更を行うことができるかについて、何か良い考えはありますか？

ありがとう、ジョー

Subversion で「ベンダー ブランチ」として git リポジトリを使用することは可能ですか?

このプロジェクトにはいくつかの部分がありますが、svn を使用する部分と git を使用する部分があります。そのため、他のプロジェクトをベンダー ブランチ (または同様のもの) として持つことができる「プロジェクト ルート」を調べています。

問題は、この「プロジェクト ルート」を Subversion で管理できるかどうかです。

ありがとうヨハン

逆の質問は次の場所にあります。

• Subversion リポジトリを git の「サブモジュール」として持つことは可能ですか?

更新：

答えが「いいえ、不可能です」と指摘してくれた VonC に感謝します。しかし、その逆です (そのため、代わりにその質問に焦点を当てます)。

シーン:ベンダーから定期的に更新される、購入した Web アプリケーション。次に、外観を大幅にカスタマイズし、独自の機能を追加したり、ベンダーが対応する前にバグを修正したりします。バージョン管理については、新しいリリースを受け取るたびに、「ベンダー ブランチ」</a> モデルに従って Subversion を使用しています。これには、バージョン管理されたシステムのバニラ コピーがあるという追加の利点があります。

問題: Mercurial に切り替えたいと考えており、おそらく安定/デフォルトの分岐パターンに従います。Mercurial は、ベンダーからリリースを 1 つだけ受け取り、そこから開発を開始する場合に最適です。しかし、何らかの理由で、ベンダーからの将来のリリースをどのように処理するかについて頭を悩ませています。

嘆願: Mercurial スタイルの「ベンダー ブランチ」に関するヘルプをいただければ幸いです。

コードベースに定期的にインポート（およびパッチ）する必要があるかなり大きなライブラリがあります。

SVN Book では、「ベンダー ドロップ」のパッチを適用したバージョンを保持する「ベンダー ブランチ」スキームを推奨しているようです。これは機能しますが、ベンダーも SVN を使用しており、reop への読み取りアクセスを許可しています。

パッチを更新する必要があるときに、ベンダー ファイルの履歴にアクセスできると便利です。

だから私の質問は：

何らかの形でベンダー ファイルの履歴へのアクセスを保持する、パッチを適用した「ベンダー ブランチ」を作成する方法はありますか?

(svn:external フォルダーについての言及を見たことがありますが、リビジョンを固定するという点で完全な影響を本当に理解しているかどうかも、それに対する独自のパッチをどのように正確に維持するかもわかりません。)

ここで取るべき正しいルートは何ですか? (FWIW、ベンダーは月に 1 回リリースします。私たちは年に 1 ～ 2 回程度更新をプルする予定です。)

ありがとう

古いプロセスは通常のsvn vendor branchでしたが、サブディレクトリをメイン コードベースにコピーしただけです。だから：

にコピーされました:

次に、新しいバージョンを追加してタグを付け、2 つのライブラリ/Zend フォルダの違いをトランク/ライブラリ/Zend にマージします。

Git でこれを行うにはどうすればよいですか?

git-svn を使用して subversion リポジトリの git clone を作成し、次に subtree merge を使用する場所を最初に考えましたが、ターゲットが実際に外部リポジトリのサブディレクトリである場合、それをどのように達成できるかわかりません。正直なところ、ドキュメンテーションやテストなど、他のすべてのディレクトリもマージしたくありません。

タグのサブディレクトリに基づいて独自のgitリポジトリを作成し、サブツリーをマージしてから、新しいバージョンをダウンロードしてそのgitリポジトリを手動で更新し、新しいディレクトリを処理し、ディレクトリ/ファイルを手動で削除する必要がありますか?自分？

Git および SVN リポジトリからの外部コード (自分で変更できる) を含むプロジェクトを Mercurial に保存したいと考えています。SVN では、ベンダー ブランチでこれを解決し、コードをコピーしますが、Mercurialでは、プロジェクトごとに異なるリポジトリを用意し、必要に応じてそれらの間でプルする方がよいことを理解しました。

プロジェクトのレイアウトは次のようになります。

In Subversion I would create vendor dir and a trunk dir, copy all external libraries first in vendor, and then in the right place in trunk. (I think) I can do this in Mercurial too, with subrepositories, but is this the best way to do this?

I tried setting up different repositories for the external libraries, but then it seems I can't pull the externalLibraryARepo into the externalLibraryA directory of my main repository? It goes in the main directory, which is not what I want. I can also create a Mercurial mirror repository and include it as a subrepo in my main repository, but then the changes in this subdirectory go to the mirror repository, while I want them to stay in the main repository.

私の質問は、以下の手順に従ってマージする場合、「ブランチをトランクに戻す」手順の最後のステップは、ベストプラクティスのシナリオでこれを行う適切な方法ですか?

私は何年もの間svnを使用してきました。私の個人的なプロジェクトでは、私は常にトランクを再考することなく楽しくハックしており、長い間、1 行の直線的な方法でバージョン管理を行うことは完璧に近いものでした。シンプルで効率的。サードパーティのライブラリをもっと制御したい日まで、すべてが至福でした。

今日、私はトランクから直接ハックするアプローチを超えたと感じるプロジェクトに取り組んでいます。私は複数のサードパーティ ライブラリを持っており、その一部は毎週変更されており、何が入るかをより詳細に制御する必要があります。サードパーティのライブラリ バージョン間で特定の変更セットを表示し、特定のライブラリに加えた変更を追跡する機能が必要です。コードベースが非常に混乱し、経験の浅いビルドマスターで実行可能な状態に戻すのが困難になるのを何度か見てきましたが、ここで失敗する余裕はありません。

そこで、ベンダーの分岐について調べ、あちこちでいくつかの記事を読みました。私は「Subversion によるバージョン管理」という優れた本を持っていますが、私が目にする例は、そのアプローチが矛盾している場合があり、「分岐」の意味を理解したいと考えています。私はEvan Weaver によるこの投稿で与えられたアプローチに従おうとしていました。

以下に手順を示しました。私の懸念は、最後のセクション「ブランチをトランクに折りたたむ」にあります。私が過去に一緒に働いたビルドマスターは通常、ブランチチェンジセットをトランクに「マージ」したようで、ブランチが削除されたとは思いません。これは適切なアプローチですか？

ブランチの作成

1 - 現在のヘッド リビジョンに注意してください。

2 - トランクのクリーンなリモート コピーをブランチ フォルダーに作成します。何か名前を付けてください。これを your_branch と呼び、HEAD_REVISION をステップ 1 でメモしたリビジョン番号に置き換えます。

3 - 新しいブランチを指すようにローカル チェックアウトを切り替えます (変更は上書きされません)。

4 - ローカル チェックアウトが確実に your_branch になり、問題なく更新できることを確認します。

5 - 必要に応じて新しい変更をコミットします。

ブランチの更新

あなたは your_branch でしばらくの間開発を行ってきました。トランクの他の人も同様です。今度は、your_branch に彼らの変更を追加する必要があります。

1 - まず、ブランチ チェックアウトを更新し、未解決の変更をコミットします。

2 - Subversion ログを検索して、変更を最後にマージしたリビジョン番号を確認します (マージしたことがない場合は、元のブランチがいつ作成されたか)。これは、マージを成功させるために重要です。

3 - 現在のヘッド リビジョンにも注意してください。

4 - トランクの最後にマージされたリビジョンとトランクのヘッド リビジョンの違いを your_branch 作業コピーにマージし、LAST_MERGED_REVISION をステップ 2 で書き留めたリビジョン番号に、HEAD_REVISION をステップ 3 で書き留めたリビジョン番号に置き換えます。

5.a - 出力でエラーを探します。すべてのファイルが見つかりましたか? 削除されるべきではないものが削除されましたか? 多分あなたはそれを間違った。元に戻す必要がある場合は、svn を実行しますrevert -R

5.b - 5.a で問題がないように思われる場合は、競合を確認し、見つかった競合を解決します。

6 - マージをコミットし、COMMAND を手順 4 の正確なコマンド コンテンツに置き換えます。

枝を幹に折り返す

ねえ、your_branch は完了です。今度はトランクにならなければなりません。

1 - まず、前のセクション (「ブランチの更新」) のすべての手順に従って、your_branch がトランクの最近の変更と同期されるようにします。

2 - トランクを完全に削除します。

3 - your_branch を古いトランクの場所に移動します。

4 - 作業コピーをトランクに再配置します。

終わり！

この手順に関するアドバイス、コメント、またはフィードバックをお待ちしております。