I'm contributing to the Harmony project, and they use subversion to store all their files. So whenever I need to send a patch with the work that I've been doing, I send it by creating an svn diff. It then gets patched by a committer, and then I can update to see my code in all its glory.

However, if I'm adding new files, I have to go through a somewhat more tortuous route (see the thread on the harmony-dev mailing list for more details). I raised the problem with Mark Phippard, who quickly added a FAQ entry and an issue describing this scenario.

The problem occurs when:

1. You have used svn add to add new files, prior to generating a svn diff for inclusion
2. Your patch is accepted and committed by someone with commit rights
3. You do an svn up to bring your codebase into line

If you follow each of these steps, you will get a message "svn: Failed to add file 'my.new.file': object of the same name already exists". It turns out that subversion isn't clever enough to figure out that exactly the same file is there that it's trying to update to, and so complains bitterly about the process.

Much swearing later, and the solution turns out to be:

1. mv my.new.file my.new.file.bak
2. svn revert my.new.file
3. svn update my.new.file
4. diff -w my.new.file my.new.file.bak (to check it's been applied correctly)
5. rm my.new.file.back (or mv my.new.file.bak my.new.file if you've been working on it since)

Unfortunately, you've got to do this for every file that you've added that can't be patched. Still, if you fix that problem and do a project-wide svn up, then at least you'll find the problems on a file-by-file basis.

I'm sure that CVS never had this problem ... oh, by the way, svn 1.5 may have a --force flag that may get rid of update problems by treating your version of the file as local changes -- check with the documentation as it's released for more.