SVN のログを見ると、いつリリースが行われたかを示すマーカーが表示されたらいいのにと思います。PVCS やPerforceなどの他のバージョン管理システムでこれを見てきました。
これはSVNで行うことができますか? 少し調査しましたが、これまでのところ、この種のことはサポートされていないようです。
リリースごとにソースを別のフォルダーにコピーする必要はありません。これにより、開発者のマシン上に膨大な量の不要なファイルが複製され 、各リリースのリビジョン番号の記録しか得られません。テキストドキュメントを使用してそれを行うことができます！
私の目標は、リリースの年表を示す単一のビューを作成することです。その間に、各リリース間で行われたすべてのコード変更を確認できます。これにより、リリース ノートの編集が容易になります。
そうではありません。SVN でリリースを行う一般的な方法は、特定のリリースごとにリリース ソースをコピーする「tags」ディレクトリを作成することです。たとえば/tags/release-0.11...箱から出してすぐに誤ってディレクトリをいじるのを防ぐものは何もありませんがtags、タグをリリースするための偶発的なコミットを防ぐために、コミット前のフックを設定することを好む人もいます。
これは、SVN でのリリース プロセスを説明するまともな記事です。
リチャード、タグは非常に近いですが、必要なのは専用のリリース ブランチではないでしょうか。
このために、「Release」などと呼ばれる早い段階でトランクからブランチを作成します。次に、通常どおりトランクで作業し、リリースの準備ができたら、トランクからの変更を「リリース」にマージします。これは、リリースを変更する唯一の方法です。
その後、必要に応じてリリースからタグ付けできますが、100% 必要ではありません。
しかし、これによって得られるのは、トランクのリビジョンのサブセットを持つブランチです。リリース日を確認するには:
svn log --stop-on-copy svn://server/project/branches/release
これにより、リリース日のリストが表示されます（リビジョン付き）。各リリースの内容を確認するには:
svn mergeinfo --show-revs=merged "svn://server/project/trunk" "svn://server/project/branches/release"@<release revision>
また、このように作業することで、トランク内のすべてのものを厳密に順次リリースすることに制限されないことに注意してください。まだリリースしたくない場合はリビジョンを除外して、後続のリビジョンを含めることもできます。
私の目標は、リリースの年表を示す単一のビューを作成することです。その間に、各リリース間で行われたすべてのコード変更を確認できます。
Tortoise SVN リビジョン グラフを調査しましたか? 各リリースにタグを付けると (他の人が指摘したように、サーバーまたはワークステーションでファイルをコピーする必要はありません)、実際のリリースを示すタグとともに、すべてのリビジョンを時系列で見ることができます。関心のある 2 つのリビジョンを強調表示し、コンテキスト メニューから diff を選択することで、リリースおよび/またはトランク間の差分を確認できます。
これを実現するには、svn リポジトリのタグ パスにトランクをコピーします。これは svn のコピーであるため、svn リポジトリ サーバー上にファイルが重複することはありません。トランク以外の svn パスをチェックアウトすることを選択した場合にのみ、ローカルにファイルが重複します。これらの作業コピーのコミットは、チェックアウト元の svn パスに戻ります。
これは基本的に、svn での分岐の特定の従来の実装です。詳細については、オンラインの svn book を参照してください。
マーカーは、リリースのタグが作成されたときに書き込まれるコミット メッセージです (/tags への svn コピー)。少なくともそれが最も一般的な方法です。
SVN Book のトピックをご覧ください。
タグとブランチは「コピー オン ライト」です。つまり、リポジトリに余分なコピーはありません。一般に、個々の開発者は、何らかの理由でローカル コピーが必要でない限り、ローカル コピーを持つ必要はありません (IE はブランチで開発しています)。
各リリースにタグを付けると、リポジトリを参照してタグを確認できます。上記のリンクはコマンド ライン ツールについて直接説明していますが、Windows には TortoiseSVN のような GUI ツールもあります。履歴を取得したり、比較したりできます。
リリースで行われた変更を確認するには、必要なタグのリビジョンから前のタグのリビジョン +1 までのトランクのログを表示するだけです。余計な作業のように思えますが、慣れてしまえばとても簡単です。
私たちのビルド ツールでは、いくつかのバージョン番号情報を含むファイルもトランクにコミットし、コメントにはビルドのバージョン番号が含まれています。メイン コードがトランクにある場合、これはビルドにあるもののマーカーとしても機能します (バージョン コミットの間を調べます)。
Subversion 自体はリリース管理を提供しませんが、通常、バージョン管理ツールはこの作業を担当しません。あなたが探しているのは、Subversion とやり取りできるアクティビティ/問題/変更管理ツールです。
そのために、私の職場では Jira を使用し、それを Subversion とリンクしています。Jira は、各リリースの問題を含むロードマップと変更履歴を提供します。これらの問題のそれぞれに、ソース コード管理の変更へのリンクがあります。したがって、ソース コードの変更をリリースされたバージョンにリンクできます。
一般的には、これら 2 つのツールを別々にしておく方がよいと思います。特に PERFORCE はこの 2 つを結び付けようとしていますが、単純にしかしていません。課題への変更をユーザーにメールで送信する、課題にコメントを追加する、課題に添付ファイルを追加するなど、Jira のような特殊なソフトウェアで行う方がはるかに優れていることがあります。一方、Jira は、ソースのバージョニング、マージ、および分岐があまり得意ではありません。これは、Subversion のような特殊なソフトウェアで処理する方が適切です。
完全な開示のために、Bugzilla、Trac、IBM Rational Jazz などの Jira 以外のツールがあり、Jira と同じことを Subversion で実行できますが、さまざまなレベルの機能があります。
コミットメッセージを使用するための+1。
プロジェクトでは、build という名前の SVN ユーザーを作成しました。ビルド マシンはこのログインを SVN に使用しました。ビルド マシン/プロセスがビルドを実行するたびに、ファイルも更新され、SVN コミット メッセージはビルドのバージョン/その他の識別子でした。
次に、そのビルドのタグも作成しました。このようにして、トランク内で、他の変更が散在するとき/場所でビルドを確認できます。
だから私の提案（それを行う最も簡単な方法）は、ビルド（またはあなたが望む他のもの）と呼ばれる別のファイルを作成し、それに追加するか、ビルドスクリプト/プロセスでそれを変更してから、名前でチェックイン/コミットすることですコミットメッセージとしてリリースバージョンの。単純。その後、履歴クエリに表示されます。
さらに、比較しているリビジョンがわかっている場合は、SVN差分を実行すると、どのファイルが変更されたか、2つのリビジョン間でどのように変更されたかがわかります。
セットアップ全体についてはわかりませんが、誰かがTortoiseSVNについて言及しました。それは間違いなく良いスタートです。私は個人的にサブクリッププラグインでEclipseを使用しており、リビジョン間のグラフィカル環境で差分を実行できます。プロジェクトがある限り、任意のリビジョンを他のリビジョンと比較できるため、あらゆる種類のファイルを複製する必要はありません。
また、通常、各リポジトリに3つのディレクトリを設定します。ブランチ、トランク、タグ。誰かが指摘したように、タグは特にリリースを識別するために使用されます。
リポジトリのルートで「tags/branches/trunk」という通常の svn 規則に従う場合、開発者は通常、リポジトリ全体をチェックアウトするのではなく、トランクからのみチェックアウトします。
私は同じ問題に遭遇し、会社のためにそれを修正しようとした方法は、トランクに「リリース」フォルダーを作成することです。このフォルダーには、実際の実行可能ファイルまたは展開の一部にする必要があるもののみが含まれています。
「リリース」フォルダーに「1.0.0.0」で始まるリリースごとに新しいフォルダーを作成し、同じリリースフォルダー名、つまりこの場合は 1.0.0.0 でコードにタグを付けます。
それが正しい方法かどうかはわかりませんが、展開した実行可能ファイルを見つけるという問題は解決します。
ご参考までに、
SVN コピーはハード コピーではありません。リンクしているだけなので、変更されたファイル以外のスペースは必要ありません。いずれにせよ、それらのバージョンは容量を消費します。そのため、リリースごとにコピーを作成してもスペースは必要ありません。