高度なsubversionテクニック、何が欠けていますか?


10

私は約9か月前にSVNの使用を開始しましたが、控えめに言ってもそれは画期的なことです。でも、まだ少し迷ってる気がします。アプリケーション開発を本当に強化するために利用しなければならないことがまだまだたくさんあるように思います。

例えば

なんらかの「サブリポジトリ」などへの揮発性/主要な変更を検疫できるようにしたいと思います。大きな変更が、非常に緊急のマイナーなバグ修正を妨げていることがわかりました。不完全なコードや壊れたコードをプッシュせずに1つの単純な更新をプッシュするにはどうすればよいですか?


3
あなたは(あなたがチェックし、SVNうまくでそれを使用することができ、あなたの地域の支店のためのHGを使用して検討する必要があり、これを
OneOfOne

ハ!水銀が足りない。
DexterW 2010

3
"Advanced Subversion"は、矛盾のように聞こえます。ローカルのみの場合は、GitまたはMercurialを使用します。
Macneil

回答:


7

あなたの例に取り組むために、それを行うには3つの可能性があります:

  1. 単一のファイルをコミットできます。リポジトリへのアクセスにIDEを使用する場合、コミットする前に単一のファイルを選択または選択解除するためのビューが考えられます。コマンドラインでsvn commit file1 path1/file2 path2、file1、path1 / file2、およびpath2の下のすべての変更をコミットするように入力します。
  2. 異なる作業用コピーを作成できます。標準の作業コピーで大規模な機能に取り組み、緊急のバグに関する情報を入手します。リポジトリを別のディレクトリにチェックアウトして、この2番目の作業コピーのバグを修正できます。バグが発生したコンポーネントのサブディレクトリのみをチェックアウトすることもできます。バグ修正後、大きな機能での作業をコミットせずに、2番目の作業コピーでコミットできます。編集:その方法は、アンナリアの答えでも説明されています。
  3. あなたはあなたのフィーチャーに関する作業のためのブランチを作成します。そのためには、copyコマンドを使用します。リポジトリに標準レイアウトを使用する場合(プロジェクト名のディレクトリと、トランク、タグ、ブランチの名前のサブディレクトリ、プロジェクトを含むトランク)、次のようにsvn-copy-commandを使用してブランチを作成できますsvn copy svn://hostname/projectname/trunk svn://hostname/branches/branch-for-feature-X。これで、作業コピーを新しい場所に切り替えることができます:svn switch svn switch svn://hostname/projectname/branches/branch-for-feature-X。バグ修正モードに切り替えると、実際の変更をコミットし、作業コピーをトランクに戻し、バグを修正してコミットし、作業コピーを機能ブランチに戻します。機能を開発する準備ができたら、トランクにマージして戻すことができます。

説明されている簡単なケースでは、通常#1(私が最も頻繁に使用します)、時には#2を使用します。ブランチの操作(ケース#3)はより複雑です(詳細はこちら)が、より多くのトリックが可能です。しかし、サブリポジトリの説明に一致するブランチ。

あなたの例以外に、私は多くを言うことはできません。Subversionには多くのことがありますが、あなたが既に何を使用していて、プロジェクトに何が必要かはわかりません。SVNの詳細については、SVN-Bookが優れたリソースです。http//svnbook.red-bean.com/


3
アプローチ#1の問題は、新しい機能とバグ修正の両方が同じファイルへの変更を伴うことにならないことを常に事前に知ることができないことです。このため、#2(機能ごとまたはバグ修正ごとの個別作業コピー)または#3(機能ごとまたはバグ修正ごとの個別ブランチ)をお勧めします。ブランチには、トランクからのチェックアウトに影響を与えずに機能またはバグ修正が完了する前にブランチで変更をコミットできるという利点があります(個別の作業コピーでは、すべてのコミットがトランクに影響します)。
スティーブンC.スチール

7

1つのコピーを取得してすべての変更を加えるのではなく、コードを別のサンドボックスにチェックアウトできます。

したがって、次のようなフォルダ構造にすることができます。

D:\Dev\MajorFeature1
D:\Dev\Bug12345
D:\Dev\MajorFeature2

これらはすべて、SVNの同じ場所からチェックアウトできますhttp://mysvnrepo/trunk

これにより、機能開発のサンドボックスに影響を与えずにバグ修正サンドボックスからコミットできますが、バグ修正のsvn updateために変更をコミットするには、他のサンドボックスから実行する必要があります。


4

Subversion Branchをまったく見ましたか?

一般的なテクニックの1つは、必要に応じて重要な修正を適用して、トランクを安定させることです。次に、重要な新しい作業ごとにブランチを作成します。そのプロジェクトに取り組んでいる開発者はブランチをチェックアウトし、ブランチにコミットします。最終的な統合の一部としてブランチをメイントランクにマージすることを決定するまで、トランクには影響しません。

別のアプローチは、特定のリリース用のブランチを用意して、トランクで他の作業が誤って実行されて問題が発生するのを防ぐことです。必要に応じて「リリースブランチ」をバグ修正し、準備ができたらそれらの修正をトランクに戻すことができます。

開発者は、複数の作業コピー(トランクとブランチ)をチェックアウトするか、svn switchコマンドを使用してトランクと特定のブランチを切り替えることができます。

(a)これにより他のユーザーとのコラボレーションが禁止され、(b)まだ機能していない変更をメイントランクに誤ってコミットするのは簡単すぎるため、個別にチェックアウトする多くの「サンドボックス」作業コピーを用意することはお勧めしません。


3

私の作業コピーの現在のサイズは10GBで、50.000以上のファイルがあります。ブランチごとにいくつかのコピーを作成できますが、新しいコピーを作成するだけでは時間がかかります。

緊急のバグが発生した場合、通常はすべての変更をパッチに保存し、すべてを元に戻し、バグに取り組み、コミットしてから、保存したパッチを適用します。新しい作業コピーを取得するよりもはるかに簡単で迅速です。これを頻繁に行う必要がある場合は、2つの作業用コピーを用意します。1つは長期的な変更用、もう1つはバグ修正用です。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.