On Sun, 2016-06-12 at 02:11 +0200, Branko Čibej wrote: > > It's not a result of merge of individual folders. I find the pattern > > in the log for commits I've done and I have most definitely not gone > > out of my way to explicitly merge several subfolders one-by-one. > > As I said, once the subtree mergeinfo is in the repository, it will be > updated in /every/ merge. > > > All users use TortoiseSVN. You think it's related to the client? > > Should I ask the Tortoise community instead? > > We'de really need a more detailed what's actually happening. I'm afraid > that for now we're only guessing based on your description of the logs; > that's far from enough. > > Personally, the few times I've used TortoiseSVN for merging, I didn't > notice it behaving in any way differently from the command-line client.
Hello, The main issue is that merge operation will add a "svn:mergeinfo" at the current working directory where operation is applied. But it is expected to be only on "root" folder aka /trunk or /branches/xxx Two ways to avoid that: guidelines to developers when merging (often fails) and precommit hook to prevent addition of svn:mergeinfo property to "non-root" folders. To cleanup an existing working-copy, I have designed a Perl script that checks if a svn:mergeinfo may be "moved" up to "root" folder: https://github.com/ymartin59/svn-clean-mergeinfo It is not "perfect" (yet... do not hesitate to report issues with test cases) but it helps a lot to reduce svn:mergeinfo sets. Then a quick human check is required to finalize: remove remaning properties and commit the result. Hope this helps -- Yves Martin
