9

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

ユースケースとして、複数のプラットフォーム固有のソース (*.c) 実装を持つ共通のヘッダー (*.h) ファイルを考えてみてください。このタイプのブランチは永続的なものです。これらのブランチはすべて、時折ブランチをまたがるマージを伴う継続的な開発が見られます。これは、一般に有限の寿命を持つ不安定な開発/安定リリース ブランチとは対照的です。

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

4

8 に答える 8

9

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

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

svn コピー svn://server/project/header.h svn://server/branched_files/header.h

次に、そのファイルを切り替えてbranches_filesリポジトリパスを使用できます

于 2008-09-22T20:42:06.137 に答える
3

悲しいことに、ここでの本当の答えは、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 クライアントの周りにラッパーを書いてすべての混乱に対処するための適切なプロジェクトがおそらくここにあります。

于 2008-09-22T20:54:50.193 に答える
3

これが私があなたの問題をどのように理解するかです。次のツリーがあります。

time.h
time.c

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

time.h は一般的です
time.c (x386 用)、time.c (ia64 用)、time.c (alpha 用)、...

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

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

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

 
/
/ヘッダー/
/headers/test.h
/ソース/
/source/test.c

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

于 2008-09-22T21:45:23.100 に答える
1

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

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

何かのようなもの：

// foo.h:
void Foo();

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

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

適切に適合しない場合、それは適切なソリューションではない場合があります。

于 2008-09-22T21:03:46.820 に答える
1

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

svn copy myfile.c myfile_branch.c
于 2008-09-22T20:33:43.990 に答える
1

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

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

于 2008-09-22T20:57:14.057 に答える
0

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

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

于 2008-09-22T21:52:54.017 に答える
0

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

于 2008-09-22T20:35:54.077 に答える