On 6/12/2016 12:39 PM, Branko Čibej wrote:
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.
And in case you wanna give it a quick try: It's included in MaxSVN's
trunk dev builds:
http://www.luke1410.de/typo3/index.php?id=97
(runs on Win Vista+ only - 64-bit)
As Brane stated, be careful and double check the results before
committing any changes.
--
Regards,
Stefan Hett
