Hi,
There have been some discussion on this in issue 1539. We ran into this issue
when performing a very large svk smerge (which is a large tree modification and
a prop change), where there are commits coming in during the merge is happening.
At the end of the merge it failed because the prop change is now considered
conflicting by svn's fs_merge. This gets worse as changes pending merge
accumulates, as it's more likely to have commits happening over a longer merge
run. The conflict comes from the svn_fs_fs__noderev_same_rep_key() check, and
there's a comment:
* // Property changes may only be made to up-to-date
* // directories, because once the client commits the prop
* // change, it bumps the directory's revision, and therefore
* // must be able to depend on there being no other changes to
* // that directory in the repository.
Which I think is invalid in the fs level, as it shouldn't care how the client is
going to represent the result of the commit, and there might not even be a wc
when we are calling the api directly to make a prop change.
I am suggesting on lifting the merge logic to conflict on prop change collisions
only in the fs level. But this would require the wc to represent the result or
having higher level of api forbidding such prop change.
Cheers,
CLK
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 3 10:31:00 2007