いくつかのリファクタリングを行った後、一度に約1000個のファイルをコミットしようとしていました。このような膨大な数のファイルをコミットすることをお勧めしますか、それともバッチでコミットする必要があります。私はある種の賛否両論を見ようとしています。
長所の1つは、すべての変更についてSVNに同じエントリがあり、ナビゲートしやすいことです。
いくつかのリファクタリングを行った後、一度に約1000個のファイルをコミットしようとしていました。このような膨大な数のファイルをコミットすることをお勧めしますか、それともバッチでコミットする必要があります。私はある種の賛否両論を見ようとしています。
長所の1つは、すべての変更についてSVNに同じエントリがあり、ナビゲートしやすいことです。
SVNは一度に1000個のファイルを処理できます。バッチをチェックインする唯一の理由は、「バグ修正#22」や「フレアの追加」など、各バッチに異なるコミットメッセージを表示することです。
ファイルの数が1000と少ないので、パフォーマンスについて心配する必要はなく、正しいワークフローについて心配する必要があります。1000ファイルは多くのファイルであり、したがって多くの変更がありますが、Subversionはそれをかなりうまく処理する必要があります。
ただし、すべての変更が実際には1つの変更ではない場合は、1つのコミットであってはなりません。たとえば、3つの関数の名前を変更する場合、それぞれの名前を個別のコミットに変更します。具体的に何をしているのかによっては、1回のコミットで解決できる場合もありますが、1年後にログを閲覧していると、小さなコミットに固執する傾向がある場合は、自分の生活が楽になります。 。それが本当に1つの変更だけである場合、1つのコミットが間違いなく最善のオプションです(たとえば、1つの関数の名前を変更します)。
ファイルの数は実際には重要ではありません。コードリポジトリに変更をコミットするときは、ビルドの安定性とテストコンプライアンスを考慮する必要があります。
それはあなたの質問に答えます:あなたがn個のファイルに変更を加え、それらのいくつかだけをコミットした場合、あなたはビルドを壊す可能性があります(テストについて話しさえしません)。したがって、少なくともビルドの整合性を保証するために、必要なすべてのファイルをコミットする必要があります。
svnおよびその他のツールは、サーバー上の単一のトランザクションを表すそのようなファイルのnbを十分に処理できます。