Re: reintegrate problem

On Wed, Mar 04, 2009 at 06:02:28PM -0500, Ruslan Sivak wrote:
> Stefan,
>
> I'm not sure you've read my post fully. I might've merged changes both
> ways, although I'm not 100% sure that I merged anything back to the
> trunk yet.

I misread the part about the copy, I thought the developer
had copied it over to trunk using svn copy (which should
create mergeinfo if not done withing a single working copy).

Stefan Sperling wrote:
> > On Wed, Mar 04, 2009 at 05:27:15PM -0500, Ruslan Sivak wrote:
> >
> >> I think I've found another 1.5 bug related to reintegrate...
> >>
> >> Some time ago we created a branch called v2. There were a lot of
> >> changes done to this branch, with some merged back to trunk and some
> >> changes merged to the branch from trunk. So far so good.
> >>
> >
> > So you've merged changes both ways.
> > You cannot use --reintegrate anymore.
> >
> >
> I don't this is true.

Yeah, Mark also pointed out that this wasn't true.
It's actually the "normal" merge (and not the --reintegrate
merge) that might not work as expected if changes have been
merged both ways. Sorry about that.

> If you read the rest of my post, you will see that the problem is not
> caused by any merges that were done, but by a directory that was copied
> from the branch to the trunk using OS copy tools.

OK, so the problem is that revision 432 was not included in the
mergeinfo created on the branch during the catch-up merge from
trunk, which causes --reintegrate to complain because there is
a gap in the mergeinfo on the branch. That I understand.

But the rest I don't understand.

Specifically, this paragraph is not clear to me:

 I guess the merge code that did the merge from trunk saw that there was
 a conflict, but that the changes were the same, so it just added the
 svn:mergeinfo of /trunk/somefolder:433-555, so now reintegrate thinks
 that that folder wasn't fully merged previously.

How can there be a conflict if the changes made on both sides
were the same?

I don't get the implication "merge code saw a conflict where
there was none -> r432 was omitted from mergeinfo".
The revision should be recorded as merged into the branch
regardless of whether conflict resolution had to be done
for it or not.

> This then caused a
> conflict which subversion resolved by itself, but put in wrong
> svn:mergeinfo values.

What do you mean by "subversion resolved the conflict by itself"?
AFAIK, Subversion always leaves conflict markers in place until
it is told to remove them.

Well, Mark seems to have gotten it.

In any case, instead of answering my questions directly, could you
provide a small reproduction shell script that starts by creating
a new repository and ends after having triggered the problem?

Attached is a template script I use for this purpose, if you need one.
Just add the necessary svn and shell commands at the end of it
so that the script eventually triggers the problem.

Such a script goes a much longer way in illustrating problems than
a thousand words, because they cannot be misunderstood. And they also
have the nice property of making it easy to reproduce the problem locally,
which is already a huge step towards getting the problem fixed.

Thanks,
Stefan