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:
- You have used
svn add
to add new files, prior to generating asvn diff
for inclusion - Your patch is accepted and committed by someone with commit rights
- 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:
mv my.new.file my.new.file.bak
svn revert my.new.file
svn update my.new.file
diff -w my.new.file my.new.file.bak
(to check it's been applied correctly)rm my.new.file.back
(ormv 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.