On Thu, Aug 30, 2012 at 03:31:34PM -0400, Q. Chap wrote:
> 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.
Please upgrade to at least 1.6.18 if possible.
Several merge-tracking bugs have been fixed since 1.6.12.
> The "unexpected" part is that there is no way to disable showing the bookkeeping/housekeeping details.
Yes, that's a known long-standing issue with the merge-tracking design.
You're by far not the only one raising concerns about this.
So far, our only answer is reduced recording of subtree mergeinfo in 1.7,
so you'll have to upgrade to 1.7 to get that fix.
Note that you need to upgrade only clients to benefit from this, the
server can stay on 1.6.x for the time being.
> 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?
Only if you use 1.7 clients exclusively to manage your branches.
> 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?
Hmm, that sounds more like a bug indeed. Can you reproduce this with
1.6.18 or 1.7.6, too? Sorry, but bug reports against old versions like
1.6.12, which was released in June 2010(!), aren't very useful at this
point.
Received on 2012-08-31 14:55:37 CEST