「GoogleCode」でホストされているオープンソースプロジェクトの1つで、「TortoiseSVNclient」で「Subversion」を使い始めたところです。それを使用するためのいくつかのベストプラクティスを取得したいと思います。デフォルトのフォルダ構造（トランク、ブランチ、タグ）に従っています。以下は質問です
どんな助けでもいただければ幸いです。
ファイルに大幅な変更を加える前に、ファイルをチェックインすることをお勧めします（早めにチェックインし、頻繁にチェックインします）。
場合によっては、トランクを安定させ、ブランチで作業し、機能の準備ができたらブランチをトランクにマージして戻すことを好む人もいますが、トランクに直接コミットすることもできます。
また、作業方法やトランクに何を入れたいか（最新の安定バージョンまたは最新の最先端バージョン）によっても異なります。
早めにではなく、すぐにチェックインしてください。ブレーンストーミングと恐ろしく不可解な疑似コードを含むアドホックテキストファイル以外にコミットするものがない場合でも、コミットします。
私は（多くの人と同じように）ある種のコード検索を行っているとき、または私が望むことを実行するプログラムを検索しているときに、あなたと同じようなプロジェクトを見つけます。私はあなたのフロントページを読み、すぐにあなたのSVNトランクを閲覧して、あなたが何をしているかを確認します。
トランクにゼロのコードがある場合、私はおそらくあなたのことをすべて忘れてしまいます。意図したデザインと疑似コードを説明するファイルが少なくともいくつかある場合は、私のアイデアを示すパッチを送信し始める可能性があります。
空のリポジトリを持つプロジェクトは、「傷がつくことのないかゆみ」と叫びます。..できるだけ早く何かをプッシュしてください。
その後、頻繁にコミットします。回帰を追跡し、有毒な改訂をロールバック/修正するのが簡単になるように、多くの小さな順序付けられたコミットメントを作成するのが好きです。
空白のベースラインプロジェクト/ソリューション構造を作成したら、チェックインします。この状態では、動作するコードはありませんが実際にはコンパイル可能であるため、空白です。原則は、チームが段階的かつ定期的に小さな変更をコミットするときに、プロジェクト全体を（少なくとも）開発全体でコンパイル可能な状態に保ち、ビルドが壊れることがほとんどないようにすることです。
トランクまたはブランチで最初のチェックインを行う必要があることを要求する法律はありません。トランクを空のプロジェクトで起動して、最初から安定している場合は、分岐して開発を実行し、完了したらトランクにマージして戻すことができます。空のプロジェクトをブランチにチェックインし、実質的なものをトランクにマージする前に、最初の作業機能または基本機能を開発することもできます。いずれにせよ、ポイント＃1に基づいて、トランクは安定していて高品質である必要があります。高品質のコンテンツのみをトランクにマージします。
繰り返しますが、このタイプの慣行には厳密な義務はありません。一部のチームは、変数名の変更の単純なリファクタリングでさえ、すべてを分岐させます。一部のチームは、単一のブランチ（トランク）ですべてを分岐/マージおよび開発することさえ知りません。すべてのチームには、この問題に関して独自のレベルのバランスがあります。私の個人的なガイドラインは、新機能や主要なバグ修正、または再設計がある場合は、それを分岐してテストすることです。文字列のスペルミスや、Webページに小数点以下2桁ではなく小数点以下4桁を表示するなどのマイナーな修正である場合は、トランクコピーを修正するだけで十分です。もちろん、「メジャー」と「マイナー」の解釈は異なるため、開発/チームリーダーは基準を確立する必要があります。いずれにせよ、変更に伴うユニット/統合テストが必要ですブランチまたはトランクが意図したとおりに機能していることを確認し、可能な限り欠陥がないようにします。覚えておくべきキーワードは常に「高品質でテスト済みのコード」です。
早めに頻繁にチェックインすることをお勧めします。
これを行うには多くの方法がありますが、私が成功した最も一般的な方法は、開発ブランチから離れて作業し、安定したポイント (マイナー バージョン リリース、マイルストーンなど) に到達したときにトランクにマージすることです。
まだ読んでいない場合は、赤い本をチェックしてください。これは、svn 情報の優れたリソースです。
新しいプロジェクトを最初から作成するとき、私は通常、次のような SVN のユーザー領域で作成します。
/svn/users/me/project1
これは、ほとんどのプロジェクトがプロトタイプを捨てることから始まり、私がこれらのブランチを使用することはめったにないためです。プロジェクトが公式になり、最初の「プロトタイプ」リリースに近づいたら、それを独自のリポジトリに移行します
/svn/project1/trunk
ブランチの使用には少し余分な作業が必要になるため、必要でない限り使用しません。これは、複数の人が同じプロジェクトに取り組んでおり、衝突が頻繁に発生する場合や、元に戻して破棄することを決定する可能性のある機能に取り組んでいるときです。ブランチで実行した場合、マージしないことを選択して削除するだけです。
すべての回答は、早めにチェックインし、頻繁にチェックインすることを示唆しています。これ以上同意できませんでした。それについて私が言うのはそれだけです。しかし、要約を次のように読みました: Subversion はどのような用途に適していますか? だからここにそれに対する答えがあります。
Subversion をアプリケーション リポジトリとして使用している企業について読んだことがあります。そのため、アプリケーション Y のバージョン X をインストールすることをサーバーに伝えます。その後、サーバーは SVN サーバーで更新を実行します。また、構成ファイルもそこに保存しました。そして、(エンド カスタマー向けの別の Web インターフェイスを介して) 構成に加えられた変更は、SVN 構成リポジトリにコミットされました。これは素晴らしいです。もちろん、彼らは Win2k3 で MS Power Shell を使用していましたが、この手法は他の場所にも適用できます。