Mark Phippard <markphip_at_gmail.com> writes:
> The current behavior is not a bug. It was intended to work the way it
> does and people had to go out of their way to write the code to make
> it happen. It is clear, in real world usage that the end result has
> side effects that suck. So work is being done to understand what
> negative results would happen if these properties were not updated and
> then whether those things can be corrected.
> Work went into 1.6 and was backported to 1.5.5 and 1.5.6 to reduce the
> creation of subtree mergeinfo, which reduces the problem. Work went
> into merge reintegrate to tolerate subtree mergeinfo, to reduce the
> consequences of having it. Now work is going on to try to minimize
> the cases where it needs to be updated.
FWIW a perspective from a newcomer to svn who is using merging on a big
I started with early 1.5, prior to the fixes above, and we had lots of
subtree mergeinfo from 'svn cp' operations that we're merge related.
svn merge --reintegrate was unusable because of this, and didn't give
With 1.5.5 or later, we aren't getting subtree mergeinfo created, and
--reintegrate is working fine. I am either having no problems at all,
or only very subtle problems with how record-only merges work:
(I have on my todo list to recheck this and make a real test case.)
I do have to either delete reintegrated branches or do record-only
reverse merges, and it would be nice if somehow merging recorded that
the changeset was a merge from a path so that the record-only reverse
merge wasn't necessary. But it's easy for me to deal with the current
So, I think the svn team has done a good job sorting out what is a very
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-08 20:16:01 CEST
- application/pgp-signature attachment: stored