Re: Failing to --reintegrate branch

On Sun, Nov 16, 2008 at 10:54 AM, Bill Moseley <moseley_at_hank.org> wrote:
> On Fri, Nov 14, 2008 at 09:04:05PM -0800, Bill Moseley wrote:
>
>> http://www.svnforum.org/2017/viewtopic.php?t=6718&sid=170a806789d3c6cab16df296906dbf6c
>>
>> suggests removing all properties except ".".
>
> Which seems to have worked. So thanks to all those that were just
> about to offer help.
>
>> The root (".") has 2601-2639
>> The bulk of those 53 mergeinfo properties have the range: 2606-2639
>> And two other files have 2620-2639
>
> So is this a bug? Or is this user error on our end? I don't remember
> if any updates or check ins where done not in the top-level directory,
> but if not would that cause this problem? That is, would being very
> careful to to do all updates and check ins from the top-level avoid
> this problem?
>
> Or is it just a problem with moving or deleting files?
>
> The question is: How do we prevent a problem like this from happening
> in the future?

Copy/move creates mergeinfo and that leads to these issues. We have
recently changed SVN to just stop doing this as it does not seem to be
worth doing for the problems it creates. In the interim, I'd suggest
just removing any mergeinfo that is created when you copy/move
something.

> BTW -- the --reintegration when smoothly w/o any conflicts.
> Considering the varying version numbers in the svn:mergeinfo
> properties I was expecting there to be some problems. Makes me think
> the mergeinfo properties were incorrectly set by svn.

There is nothing in your numbers that looked incorrect. Everything is
actually working as it is expected to work. It is just that when you
put it all together, the final outcome is not desirable.

In Subversion's trunk there have been two improvements made:

1) The checking reintegrate does is a lot smarter. So even if you
have subtree mergeinfo it is not going to just bail out and complain
about it. Instead if will analyze the subtree mergeinfo to make sure
the branch you are reintegrating is properly in synch with trunk and
proceed as normal.

2) When you copy/move we will no longer create mergeinfo. So this
will have a couple of benefits. The first is that it will reduce the
need for reintegrate to be smarter since you will generally not have
any of this to begin with. The second, is that since you will not
have subtree mergeinfo you will not see the issue of merge always
updating the subtree mergeinfo.

We still think that latter behavior is necessary and that has not been
changed in current trunk. In the long run, we still want to look for
ways to change this behavior too, but we have to examine all of the
negative ramifications first and see what can be done to resolve the
issues that will arise if we do this.

With the change to copy/move the only people that will have subtree
mergeinfo will be those that cherry-pick merge revisions into specific
subtrees and in that situation it makes sense to continue to keep that
information in synch on future merges.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org