I'm not subscribed and would appreciate an explicit cc: please! Can I reliably determine if a specific revision is exclusively the result of one or more merge operations? Without resorting to parsing difference listings?
It seems I can detect merges by using 'svn log -g -xml -r <rev>' and looking for more than one <logentry>. I see all but the first will have the reverse-merge="false" property and are the ones that show up as "Merged via: <rev>". But it seems enough to simply detect more than one. (If there's a better way, do tell!) However, that doesn't seem to guarantee that those were the only changes. If I have to parse difference listing or compare mergeinfo, it's probably not worth the effort for what I want to do. So hoping, there's something relatively straightforward that I've missed. Say I have the following branches: ^/rel/v2025.1 ^/rel/v2025.2 And, that whenever a change is made to 2025.1, it is merged forward into 2025.2. User guidance is that merges should be checked in without unrelated changes (fixing conflicts ok, new code not ok), but this isn't enforced. I want to differentiate between those revisions that are due to a merge vs those that are due to "new" changes, even if they also have merges. Thanks for any guidance, Brian
