On Thu, Aug 30, 2012 at 12:36:54PM -0400, Q. Chap wrote:
> 1. I forked a branch from /branches/boring_new_stuff to /branches/awsome_stuff.
> 2. /branches/boring_new_stuff development has continued full speed. (300+ files changed over many commits)
> 3. I made some changes to /branches/awsome_stuff. (15+ files changed over 5+ commits)
> 4. Ran "svn merge ^/branches/boring_new_stuff" in my "awsome_stuff" WC. Did not commit.
> 5. Thus, my WC should exactly reflect the content of /branches/boring_new_stuff, _except_ for my branch's modifications.
> 6. Ran "svn diff --old=^/branches/boring_new_stuff --new=."
>
> I expected that step 6 would produce a small diff that is the culmination of content changes made to /branches/awsome_stuff vs. /branches/boring_new_stuff.
>
> However, two unexpected things happened:
>
> 1. I see hundreds of spurious svn:mergeinfo entries.
> 2. A few files that changed in /trunk but that I _never_ modifed in /branches/awsome_stuff are also included in the diff. Oddly, these are all binary files.
>
> Is #2 a bug?
Is suspect the following:
You're not using a 1.7 client to do this merge, and you have a lot of
existing subtree mergeinfo in the branch. So you get subtree mergeinfo
recorded on files that are unrelated to the actual changeset being merged.
In which case upgrading to 1.7 is the remedy, see
http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording
The binary files you see in the diff might also have received
svn:mergeinfo changes, and hence show up in the diff. The file content
isn't diffable so Subversion prints a placeholder instead of an
empty diff (it cannot tell whether or not the diff is empty since
it cannot compare the files).
Does this theory match your situation?
Received on 2012-08-30 20:06:44 CEST