> > > > 3. Running the above diff also outputs lines related to some files that > > > > I know I never modifed, but did recive updates via the merge. Oddly, > > > > these are all binary files. > > > > > > > > Index: Path/to/bin.dat > > > > =================================================================== > > > > Cannot display: file marked as a binary type. > > > > svn:mime-type = application/octet-stream > > > > > > > > What does this indicate? > > > > > > Not sure. Did these files also receive mergeinfo changes perhaps? > > > > > > No, those files do not have any mergeinfo at all. At least for the couple > > I checked. They do have changes brought in by the merge, though. > > > > Does this make any sense? > > Ah, in that case the files are modified so they show up in diff output. > Are you confused by the fact that Subversion cannot display diffs > for arbitrary binary files? It only supports diffing text files. >
I don't _think_ I'm getting confused... I don't expect to even see those files listed in the diff in the first place. To clarify, the basic use case is: 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? The larger reason for this is in the case of vendor drops. For instance: 1. A new library has been added as /vendor/libcomplex/1.0 tag. 2. The above has been svn copied to: /project/trunk/libcomplex 3. Patches to the project-local copy of libcomplex have been made. (per red-bean book.) 4. <time goes by> 5. Vendor drop via current -> /vendor/libcomplex/2.0 tag is added to the repo. 6. Vendor changes are merged (but not commited) to a working copy based on: /project/branches/awsomestuff/libcomplex Now, I want to test and review the old 1.0-era patches to the libcomplex-2.0 code prior to committing the merge. Maybe they will be kept. Maybe changed. Maybe removed.
