> > > > 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.
Received on 2012-08-30 18:38:43 CEST