トランクに関するドキュメントはほとんどありません。それらは特定のリリース用に更新され、リリース番号でタグ付けされ (トランク上のドキュメントは移動します)、リリース メールで会社全体に公開されます。問題 – タグ付けされたドキュメントに必要な変更を特定しています (たとえば、どこかでタイプミスがあるか、モジュールに記載されているリビジョン番号が RN で間違っています)。トランクのドキュメントを更新して、新しいタグを作成すると言うかもしれません。
リンクがまだ機能しているリリースメールを再送信せずに、タグの削除と再作成を奨励せずに、これをどのように処理できるか疑問に思っています (これは将来的に悪い慣行を生み出します)。
何かが明確でない場合はご容赦ください。詳しく説明させていただきます。
これは、率直に言って、新しいリリースを作成する必要があるように思えます。
まだ整っていない場合は、リリースの作成を自動化することをお勧めします。たとえば、リリースを作成するのに 30 分しかかからない場合 (コンパイル、テスト、タグ付け、リリース ログの更新、メールの回覧)、それほど苦労する必要はありません。
その上で、支店が必要だというあなたの会社の意識を高めたいと思います。
私はあなたが正しく理解できたことを願っていますが、同時に恐れています - 私が間違っていたら訂正してください。
トランクでのみ作業が許可されている場合に古いバージョンを「修正」するには、私の頭に浮かぶ唯一の解決策は、トランクをブランチとして悪用することです: リビジョン 56 の mydoc.txt 内でエラーを見つけたとしましょう。人々は楽しく繰り返し取り組んでいました。多くの変更の後、最後のコミットはリビジョン 89 になりました。
ここで起こったことは、1 から 3 まで、実際にブランチで作業したということです。この残虐行為を修復するには、4 と 5 が必要です。
SVN は、正当な理由で 1-5 の IMHO を実行することについて考えさせてくれます。この操作は別のブランチで実行する必要があります。古いバージョンの変更を注文する顧客については言うまでもなく、少なくともこの種の状況では、適切なブランチを選びます。
タグ付けされたバージョンをそのままにして、トランクのエラーを修正 (または、これらの修正のためだけに新しいブランチを作成) してから、新しいタグを作成し、更新された電子メールを送信するという長い道のりをお勧めします。
より痛みを伴いますが、長期的には問題が少なくなります。ドキュメント参照は自動的に計算される必要があるため、すべての変更を反映することで手作業が減り、エラーが発生しにくくなります。
新しい更新メールを送信することが問題になる場合は、リリース前にリリースするものを 2 回 (または 3 回) 確認してください。ただし、バグはリリース後まで検出されない傾向があることを知っておいてください。
もう 1 つのオプションは、上記のブランチをベータ テスターに公開し、最小限のエラーが残っていることを十分に確認してからタグを作成することです。