Subversion：古い機能ブランチの削除と維持

Question

標準レイアウト、つまりtrunk /とbranches /（およびtags /）のSubversionリポジトリがあります。大きな変更を行う場合、機能ブランチが使用され、定期的にトランクと同期され、後でトランクに再統合されます（現在は1.5を使用しています）。かなり標準的なもの。

私が疑問に思っているのは、そのような機能ブランチを、いったん終了してマージしたら、そのままにしておくか、削除するかです。 Subversionの本は、それらを削除するのが一般的であると時折示唆しているように見えますが、ブランチを保持するオープンソースプロジェクトもたくさん見ました。

ブランチを削除するとどのブランチが存在するかを追跡するのが難しくなり、特に重複する可能性のある名前がシナリオに入った場合（2回検索リファクタリングした場合など）、コミット履歴がどこかで消えてしまうことも少し心配ですリポジトリなどの

一方、ブランチは非常に多く使用されており、特に現在1.5では、非アクティブなブランチの大きなリストを調べて現在作業中のブランチを見つける必要がないという考えが好きです。

不足している長所と短所は何ですか？人々は何をしていますか？

Answer 1

それらを忘れないように本当に削除するのが心配な場合は、「非アクティブ」というブランチの下にフォルダーを作成し、古い非アクティブなブランチをそのフォルダーに svn move するだけです。これはあなたにとって両方の世界で最高かもしれません。

Answer 2

これらは安全に削除できます。それらを削除してもリポジトリから削除されることはなく、割り当てられたスペースが再利用されることはありませんが、プロジェクトツリー全体がクリーンアップされているように見えます。

Answer 3

私は作業が終わったときに機能ブランチを削除してきました。散らかっていないのが好きだからです。他の一部の開発者には多少の混乱がありましたが、バグ追跡システムにコミットのリビジョン番号を記録しているため、非常にスムーズです。誰かがブランチを見つけられないと言ってきたら、log / diff / checkout / whateverで -rrevision フラグを使用することをお勧めします。

Answer 4

混乱を防ぐために、私のチームはそれらを削除します。結局、消えるようなものではありません。必要に応じて取得できます。再び見つけるのは難しいことは確かです：ブランチが存在するリビジョン番号を知る必要があるので、ファイルを見るためにクライアントにそのリビジョンを見ることを伝えます。

プロジェクト管理にFogBugzを使用して、リビジョン番号によってSVNリポジトリにコミットされた時期を追跡します。これを使用して、ファイルを表示するためにどのリビジョンに戻す必要があるかを判断できます：FogBugzで機能履歴を見つけ、ブランチが存在したリビジョンを確認し、その情報を使用して後方にジャンプします。