Merging across branches in Subversion isn't adding all the new files. Why not?

Question

I've got a source code tree in subversion with several branches. I've just finished a fairly intense debugging session in an otherwise active branch and now need to merge the changes across to the new branch. The new branch was taken off trunk (which represents released code) recently, after all the development in the old branch (obviously) but before I committed all my debugging. Attempting to svn merge, however, doesn't merge across all the files that were added. It adds some, but not all.

Here's the time line:

• Branch off trunk to create branch dev1.
• Code in dev1, modifying files and adding files.
• Branch off trunk to create branch dev2.
• Bug fix in dev1, modifying files but not adding files.
• Merge all changes in dev1 over to dev2.

As expected, there are many changes, including new files, but not all of them. Is it because the range of versions I'm merging from includes the version that made the dev2 branch? Or should I be merging to trunk and then down to dev2?

Edit: All code is fully committed into Subversion. But I think what might be happening is that file additions do not propagate through merges. That is, a prior merge to dev1 added a few files, but a merge from dev1 that encompasses the commit from the prior merge does not include the added files.

But I'm still checking.

Answer 1

The following statement is not true:

Files that were added to a branch and then changed on the branch don't get added when doing a merge across number of revisions

That would imply merging is totally broken.

When you do the merge, you need to make sure that you do merge the revision that created the file, otherwise you'll get those warnings about no target.

The other thing to watch out for is if you do a merge into a working copy, then decide you're not happy with it and revert everything, the newly added files will still be in the working copy, so if you merge again, the unversioned files will prevent the merge of new files there, so you will miss them. So running "svn status" and removing unversioned files will ensure the merge works properly.

The comment about adding an empty file should not be done, because then the new file has no history of where it came from. In other words, it's not a copy, so "svn log" will not show its history. And finally, if the file were a gigabyte photo, you wouldn't want to merge it into a new file, because then the repository would have two copies of the exact same context. Merging and copying with history saves repository storage (at least until rep-sharing is put in).

Answer 2

I have always known svn warnings to be subversion's indication that you screwed up somehow. Then I ran into the above case where I was getting a lot of skipped files on a merge from a branch, but I knew I had the correct paths for the merge. The skipped files were all files that were added and changes on the branch but did not yet exist on trunk.

Then I realized that all of these files already existed, though unversioned, on my working copy of trunk -- I had done a test merge (not a dry run) a week earlier and reverted, but the files never got physically removed by my SVN client. As soon as I deleted them physically from my working copy of trunk the issue went away!