It sometimes happens to me that I forget to include a file in a changeset (i.e. a commit of a number of changed files that belong together, e.g. "Fixes bug #45")
I will usually just make a second commit with the same commit message.
Is there a clever and simple way to add the "latecomer" to the first commit somehow? Without svn dumping and svndumpfilter ing?
No. You could change the original commit message though to have it indicate the other commits that it should go with, or that it is multipart.
ie. "Fixes bug #45 (1/2)", or "Fixes bug #45 (see also rev 1232,1233)"
You need to make sure that you have a pre-revprop hook installed on your server to allow you to edit the commit notes
No there is nothing like this in SVN. I would suggest to make the second log message
- Followup to bug #45
- Followup to revision 123132
No, there isn't a clever way to add files to a commit in SVN. It's a side effect of truly atomic commits. Once the commit is completed, it's complete. It it were any other way, then the commit wouldn't be atomic, as it would still be waiting for the "latter" files to be added.
It seems you've explored the obvious techniques of rolling back the commit by using "svn dump" and "svn dumpfilter". The only other options are to grab a backup of the SVN tree "just prior" to making a commit mistakenly. Good luck on your mistake prevention algorithm!
If you really find it annoying, I guess you could put in a pre-commit hook to make the backup, but that has it's own issues. You might not recogonize that you forgot the file before someone overwrites the backup, and commits will likely take a long time (due to the backup).
The best solution seems to be to annotate your commits as being part of the change set for the same bug. That way searching for a fix on the bug will pull up two entries in the log, which basically describes both commits were necessary to "fix" the issue. This can have some impact on integration tools, as if you are using hooks or tools to examine your logs, they should survive multiple commits on a single bug. Often this means a manual update of the bug as "ready to build" because you never know when the bug is fixed by one commit, or if it needs another commit to finish it off due to forgetfulness.