Svn mergeinfo appearing on sub-directories

Further information on this... it's definitely not related to the authz
as the same behaviour happens when using the file: protocol. It appears
to be to do with the mergeinfo that's already present, as if I delete it
all then it works as expected.

When doing a merge, is the mergeinfo anywhere other than the source and
target trees taken into account somehow?

Failing all else my next step will be to attempt to debug with svnkit,
as I don't know C very well.

Cheers, jamie

Morning,

Recently, when any user merges up from trunk to their topic branch, svn
appears to do it directory by directory for immediate sub-directories of
the branch root, so each sub-directory gets explicit mergeinfo.

[X:\XYZ.11650]svn merge http://svn.example.net/ABCD/Source/trunk
--- Merging r38851 through r39538 into 'Automation':
U Automation\TestingDashboard\TestingDashboard.sln
...
--- Merging r38851 through r39541 into 'Tools':
...

Up to around 6 months ago this would not have been noticed, however we
have had so many problems with mergeinfo that there is now a hook that
prevents mergeinfo going anywhere other than the "branch" roots. The
hook is working fine, the problem is that svn is doing this, when there
seems to be no apparent reason.

I understand that this would happen if the user did not have read access
to one of the sub-directories in the source tree, but this is not the
case. I have compared a svn ls -R using the file protocol with the same
using the http protocol, just to be sure, and there is no difference.

It could also happen if the target wc was not at infinite depth, but
that's not the case either, nor switched sub-dirs, or anything similar.

There is no sub-tree mergeinfo on the trunk.

What other problem could be causing this?

Cheers, jamie

===============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===============================================================================
Received on 2011-06-09 13:18:59 CEST