On 12.06.2016 10:06, Yves Martin wrote: > 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.
Yes, as I noted above; and this is necessary in order to make 'svn merge' work correctly. > But it is expected to be only on "root" folder aka /trunk or /branches/xxx I'd rather say 'desired', not 'expected'. :) > 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 Let me point you at: https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-mergeinfo-normalizer This is not part of any Subversion release yet, but it's fairly complete feature-wise and could surely use a lot of testing in real-world environments. -- Brane
