Re: vendor branch merge: how to highlight patches for review?

> 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
>

Yes. I run 1.6.12.  I think the svn admins are planning to just move to 1.8 whenever that hits and looks stable.

The "unexpected" part is that there is no way to disable showing the bookkeeping/housekeeping details. Certainly they are often important to review, but not in this case, when I just want to know about the content of my codebase.

I guess it's a fine line between what svn properties you can consider "part of", or at least closely tied to, a particlair point-in-time view your codebase and what props are related to svn's automatic management of said codebase.

My gut feeling is that svn:mergeinfo falls squarly in the latter. </$0.02>

Anyway, I think I understand what's happening. Thank you for explaining. :-)

Side question:  When I move to svn 1.7/1.8 will the extra mergeinfo data be "cleaned up", or am I stuck with it for the life of this repository?

> 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?
>

Not an exact match to my senario. Those files do not have any mergeinfo.  At least for the couple I checked with "svn proplist".

Also, none of them had any "Property changes on: Path/to/bin.dat" lines in the diff output.  Just:
 
   Index: Path/to/bin.dat
   ===================================================================
   Cannot display: file marked as a binary type.
   svn:mime-type = application/octet-stream

The point is, I'm trying to figure out why svn is even attempting to show me a diff of the file content in the first place.  

Again the diff command used was:
"svn diff --old=^/path/to/parent/branch --new=."

Sure, the file(s) received a content update as part of the sync merge, but now all the properties and content _are_ exactly the same as the parent branch.  The child branch never made any changes to these files, so why should they be listed in the diff?  
Received on 2012-08-30 21:49:57 CEST