I work on a large repository (2 million plus commits, 600k files, 70GB total size) where trunk commits are frequent and happen by the minute. Our repository has been around for so long our mergeinfo is unreliable. We've had some major upgrades to our server over the past 10 years. We used to merge at root until our repository got so massive we had to shift over to subtree merges. After years of subtree merges our mergeinfo is all over the place.
When a new project comes up we branch from trunk and keep that branch alive for months, sometimes years at a time, which requires regular merges from trunk back into our branch. Before we merge our branch back into trunk we run diffs to confirm changes made on the branch. However, with commits frequently happening on trunk those diffs are only relevant immediately after we've merged trunk into our branch. We don't have the flexibility of locking trunk every time we want to run a diff. Note that we are diffing from the point of branch copy (--stop-on-copy) to the HEAD of the branch. We are running subversion server 1.9.7 with subversion client 1.14.0. I've searched for answers to this question, and perhaps I've been using incorrect terminology or framing the question wrong. Here goes: Without running third party software, is there a reliable way to determine which of the commits on our branch are merges coming in from trunk? The docs say that mergeinfo can be unreliable for a variety of reasons. We could always parse standardized commit messages in our logs, but hiding critical data like that in our commit messages just doesn't seem like a reliable approach. Thanks in advance, wispan
