Subversionの使用法[終了]

Question

＆quot; Subversion＆quot;の使用を開始しました。 「亀SVNクライアント」を使用「Google Code」でホストされている私のオープンソースプロジェクトの1つです。それを使用する上でいくつかのベストプラクティスを取得したいと思います。私はデフォルトのフォルダ構造（トランク、ブランチ、タグ）に従っています。以下は質問です

1. 最初のチェックインはいつ行いますか？一連の機能が終了した後ですか、それとも開発の初日からですか？
2. 最初のチェックインはどのディレクトリに行きますか？それは「トランク」にありますか？または、「支店」にチェックインします。そして「トランク」にマージします;機能が完成したら。この場合、「トランク」機能が完了するまで空になります。
3. 変更が行われると、「トランク」にチェックインしますか？直接？そうでない場合、作業コピーは常に＆quot; branch＆quot;を使用します。ディレクトリ、右？

ご協力いただければ幸いです。

Answer 1

1. ファイルに大幅な変更を加える前に、ファイルをチェックインすることをお勧めします（早期チェックイン、頻繁にチェックイン）。

2. 場合によっては、トランクを stable にして、機能の準備ができたらブランチをトランクにマージしたい人もいますが、直接コミットすることもできますトランク。

3. それはまた、あなたがどのように仕事をし、トランクに何を入れたいかにも依存します（最新の安定バージョンまたは最新の最新バージョン）。

Answer 2

早めに頻繁にチェックインすることをお勧めします。

これを行うには多くの方法がありますが、私が成功した最も一般的な方法は、安定したポイント（マイナーバージョンリリース、マイルストーンなど）に到達したときに開発ブランチをオフにし、トランクにマージすることです。

まだお持ちでない場合は、赤い本、svn情報の素晴らしいリソースです。

Answer 3

最初から新しいプロジェクトを作成するときは、通常、SVNのユーザーエリアで作成します

/svn/users/me/project1

これは、ほとんどのプロジェクトが使い捨てのプロトタイプとして開始され、私はこれらのブランチをほとんど使用しないためです。プロジェクトが公式になり、それに近づくと、最初の「プロトタイプ」になります。リリース独自のリポジトリに移行します

/svn/project1/trunk

ブランチの使用には少し余分な作業が必要なので、必要でない限りブランチを使用しません。複数の人が同じプロジェクトで作業していて、衝突が頻繁に発生したり、私が元に戻して破棄することを決定する可能性がある機能に取り組んでいるときです。ブランチで行う場合、マージせずに単に削除することを選択できます。

Answer 4

すべての回答は、早めにチェックインし、頻繁にチェックインすることを示唆しています。これ以上同意することはできませんでした。だからそれについて私が言うすべてです。ただし、概要は次のように読みます。Subversionはどのような用途に適合しますか？そのための答えがここにあります。

Subversionをアプリケーションリポジトリとして使用している会社について読みました。そのため、アプリケーションYのバージョンXをインストールすることをサーバーに伝えます。その後、サーバーはSVNサーバーで更新を実行します。また、構成ファイルもそこに保存しました。そして、構成に加えられた変更（エンドユーザー向けの個別のWebインターフェース経由）は、SVN構成リポジトリーにコミットされました。これは素晴らしいです。 「これらの人はWin2k3でMS Power Shellを使用していましたが、それでもこの手法は他の場所に適用できます。

Answer 5

早めにではなく、すぐにチェックインします。ブレインストーミングと恐ろしく不可解な擬似コードを含むアドホックテキストファイル以外にコミットするものがない場合でも、コミットしてください。

私は（多くのように）何らかのコード検索を実行している間、または私がやりたいプログラムを検索しているときに、あなたのプロジェクトと同じようにプロジェクトを見つけます。フロントページを読み、すぐにSVNトランクを参照して、何をしているかを確認します。

トランクにコードがゼロの場合、おそらくあなたのことはすべて忘れてしまいます。少なくとも、意図した設計を説明するファイルと疑似コードがあれば、私のアイデアを示すパッチの送信を開始するでしょう。

リポジトリが空のプロジェクトでは、「傷がつかないかゆみ」が叫びます。 ..そのため、できるだけ早く何かをプッシュしてください。

その後、頻繁にコミットします。私は、回帰を追跡し、毒性の修正をロールバック/修正するのが簡単になるように、多くの小さな秩序あるコミットメントを作成するのが好きです。

Answer 6

1. ベースラインプロジェクト/ソリューション構造を作成したら、チェックインします。ブランク。この状態では、動作するコードはありませんが、実際にはコンパイル可能であるためです。原則として、チームが小さな変更を段階的かつ定期的にコミットし、ビルドがほとんど壊れないように、開発全体を通してプロジェクト全体を少なくともコンパイル可能な状態に保つことです。

2. トランクまたはブランチで最初のチェックインを行うことを義務付ける法律はありません。空のプロジェクトでTrunkを起動して、最初から安定してから、分岐して開発を実行し、完了したらTrunkにマージして戻すことができます。また、空のプロジェクトをブランチにチェックインして、トランクに実質的な何かをマージする前に、最初の作業または基本機能を開発することもできます。いずれにしても、ポイント＃1に基づいて、トランクは安定していて、高品質である必要があります。高品質のコンテンツのみをトランクにマージします。

3. 繰り返しますが、この種の慣行には厳密な義務はありません。一部のチームは、変数名の変更の単純なリファクタリングでさえ、すべてを分岐します。一部のチームは、すべてを単一のブランチ（トランク）で分岐/マージおよび開発することさえ知りません。すべてのチームは、この問題に関して独自のバランスのレベルを持っています。私の個人的なガイドラインは、新機能や主要なバグ修正、または再設計が予定されている場合、テストのために分岐します。文字列のスペルミスのような軽微な修正や、Webページで2桁ではなく小数点以下4桁を表示する場合は、トランクコピーを修正するだけで十分です。もちろん、「主要」の解釈対「マイナー」開発/チームリーダーが標準を確立する必要があるため、状況は異なります。いずれにせよ、ブランチまたはトランクが意図したとおりに機能していることを確認するには、変更に伴うユニット/統合テストが必要です。覚えておくべきキーワードは、常に「高品質でテスト済みのコード」です。