質問

Subversion のブランチの概念は、開発を行うリポジトリ全体の不安定なフォークを作成することに焦点を当てているようです。個々のファイルのブランチを作成するメカニズムはありますか?

使用例として、複数のプラットフォーム固有のソース (*.c) 実装を含む共通ヘッダー (*.h) ファイルを考えてみましょう。このタイプのブランチは永続的なブランチです。これらのブランチはすべて、時折ブランチ間のマージを行いながら継続的に開発が行われます。これは、一般的に寿命が有限である不安定開発/安定リリース ブランチとは対照的です。

しないでください トランクとすべてのブランチの間で継続的にマージを行うと、不当な量のメンテナンスが発生するため、リポジトリ全体を (安価かどうかに関係なく) ブランチしたいと考えています。現在、私は ClearCase を使用しています。これは、これを容易にする分岐の異なる概念を備えています。SVN への移行を検討するよう依頼されましたが、このパラダイムの違いは重要です。私は、安定版リリース ブランチをカットするなどのことよりも、個々のファイルの代替バージョンを簡単に作成できることの方がはるかに心配しています。

役に立ちましたか?

解決

悲しいことに、ここでの本当の答えは、ClearCase が Subversion よりもこの状況にうまく対処できるということだと思います。Subversion では分岐する必要があります すべて, ただし、ClearCase では、特定のファイル グループのみが分岐され、残りのファイルは依然としてトランク (または指定したブランチ) に従うことを意味する、一種の「遅延ブランチ」のアイデアが許可されています。

ここで提供されている他の解決策は実際には意図したとおりに機能せず、ファイルを別のパスにコピーするだけです。このファイルを実際に使用するには、奇妙なことをする必要があります。

えー、ごめんなさい。それはあまり良い答えではありませんでした。しかし、Subversion にはこれに対する良い解決策がありません。そのモデルはブランチとマージです。

編集:OK、crashmstr が言ったことを拡張します。これを行うことができます:

svn cp $REP/trunk/file.h $REP/branched_files/file.h
svn co $REP/trunk
svn switch $REP/branched_files/file.h file.h

しかし、すごいですね、それは間違いを起こしやすいのです。svn st を実行すると、次のように表示されます。

svn st
    S  file.h

ちょっとうるさいですね。また、大規模なソース リポジトリ内でいくつかのファイルやモジュールを分岐させたい場合、非常に面倒なことになります。

実際、ここにはおそらく、ClearCase の svn プロパティとスイッチングを備えた分岐ファイルのようなものをシミュレートし、すべての混乱に対処するために泥沼の標準 svn クライアントの周囲にラッパーを作成するためのまともなプロジェクトがあるでしょう。

他のヒント

リポジトリ全体をブランチする必要はありません。プロジェクト内にフォルダーのブランチ (インクルード フォルダーなど) を作成できます。他の人が指摘したように、単一のファイルだけを「コピー」することもできます。ファイルまたはフォルダーのコピーを取得したら、ブランチされたファイルまたはフォルダーに「切り替え」て、ブランチ バージョンで作業します。

リポジトリ内に別のブランチ フォルダーを作成した場合は、サーバー側のコマンドを使用してブランチ ファイルをそこにコピーできます。

svn copy svn://server/project/header.h svn://server/branched_files/header.h

その後、そのファイルを使用するように切り替えることができます。 branches_files リポジトリのパス

私はあなたの問題をこのように理解しています。次のツリーがあります。

time.h
time.c

複数のアーキテクチャではそれを拒否する必要があります。

time.h is comon
time.c (for x386), time.c (for ia64), time.c (for alpha),...

また、現在の VCS では、time.c から必要な数のブランチを作成することでこれを行うことができ、VCS からファイルをチェックアウトすると、共通トランクからの最新の time.h とブランチからの最新の time.c が自動的にチェックされます。あなたは取り組んでいます。

あなたが懸念している問題は、ブランチをチェックアウトするときに SVN を使用する場合、トランクから time.h を頻繁にマージする必要があり、そうしないと (トランクと比較して) 古いファイルで作業する危険があり、その量のオーバーヘッドは許容できないことです。あなたへ。

ただし、ソース コードの構造によっては、解決策がある可能性があります。あなたが持っていると想像してください

 
/
/headers/
/headers/test.h
/source/
/source/test.c

次に、/ を分岐して、 SVN:外部 ヘッダーをトランクのヘッドにリンクする機能。これはディレクトリ上でのみ機能し、test.h へのコミットバックに関していくつかの制限があります (機能するにはヘッダー ディレクトリに移動する必要があります) が、機能する可能性があります。

Subversion の「ブランチ」は、リポジトリ内の何かの単なるコピーです。したがって、ファイルを分岐したい場合は、次のようにするだけです。

svn copy myfile.c myfile_branch.c

単一のファイルを分岐することにあまり意味はないと思いますか?トランクコードでテストする方法はないのでしょうか?

変更を取り消して後で適用したい場合は、代わりにパッチを取得することもできます。

本当にこの機能が必要ですか? VCS 内で ?

C プリプロセッサを使用して #ifdef を使用して不要なコードを削除してみてはいかがでしょうか。または同様のツール。

何かのようなもの:

// foo.h:
void Foo();

// foo_win32.c
#ifdef _WIN32
void Foo()
{
   ...
}
#endif

// foo_linux.c
#ifdef _GNUC
void Foo()
{
   ...
}
#endif

場合によっては、それが適切に適合しない場合、それは正しい解決策ではないことになります。

SVN のブランチは単なるコピーです。希望どおりに実行するには、ファイルの各バージョンをリポジトリ内の個別のディレクトリに配置し、それをソース フォルダーにチェックアウトする必要があると思います。I.E.そのファイルを別のプロジェクトのように扱います。

Subversion のブランチはまさにあなたが話しているものです。変更したファイルを除き、すべてのファイルはトランクの正確なコピーです。これは、SVN Book で説明されている「安価なコピー」方法論です。唯一の注意点は、そこで行われた変更が確実にブランチに反映されるように、トランクをブランチに時々マージする必要があることです。もちろん、これらの変更が望ましくない場合は、トランクからブランチへのマージを行う必要はありません。

トランクの変更を自動的にマージできるようにする簡単な方法 (Clear Case パラダイムをシミュレートする) の 1 つは、コミット前フック スクリプトを使用して、コミット前にトランクの変更をマージすることです。(実際、これは常にコードのドリフトを防ぐための優れた戦略)。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top