Svn のリポジトリに既にコミットした後で、多数のコミットされたファイルを (単一のコミットとして) グループ化することは可能ですか?
大量のファイルをコミットした後 (subeclipse を使用していない場合)、常に 1 つまたは 2 つのファイルを忘れているようで、これが可能かどうかを誰かが知っているかどうか疑問に思っていました。
Svn のリポジトリに既にコミットした後で、多数のコミットされたファイルを (単一のコミットとして) グループ化することは可能ですか?
大量のファイルをコミットした後 (subeclipse を使用していない場合)、常に 1 つまたは 2 つのファイルを忘れているようで、これが可能かどうかを誰かが知っているかどうか疑問に思っていました。
一度コミットすると、それを変更する方法は意図的にありません。このように、r123 は常に同じものを参照します。後でコミットにファイルを追加できた場合、変更前に r123 をチェックアウトした人は、変更後に r123 をチェックアウトした人とは異なるビューを持つことになり、バージョン管理システムの重要な目標が破られます。
これは、「構文エラーがあり、ビルドできないコードをコミットしたらどうすればよいか」という質問とまったく同じです。答えは、修正が含まれている別のものをコミットすることです。2 つのケースは、同じ問題を引き起こし、同じ解決策を持っています。
いいえ、この種のパワーにはGitのようなツールが必要です。
上位レベルのツールを使用してリビジョンをグループ化し、変更を追跡する最適なソリューションを見つけました。
redmine を使用してすべてのタスクを文書化し、svn リビジョンはそれに対して自動的にスタンプされます。このようにすると、修正に 7 ~ 8 回のコミットが必要になる場合がありますが、ログをすばやく検索して、バグ #366 の修正を 1 つのユニットとしてリリースすることができます。
Redmine、trac、fogbugz、bugzilla、tfs など、すべて問題ありません。
以前の回答をフォローアップするには。
この時点では、 Git SVNをほぼ独占的に使用しています。これは、ローカル リビジョンを保持し、機能を完全に使い終わったときにそれらを SVN ツリーにマージできるためです。Git SVN を使用する場合、変更をローカルにコミットし、完全に完了したら、SVN に同期します。
回避策: 問題のすべてのリビジョンを逆マージし、コミットし、それらのリビジョンからの変更を WC に再度適用し、一度にすべてコミットします。
免責事項:私は試していません。