On Tue, Jul 21, 2009 at 03:34:36PM +0200, Neels Janosch Hofmeyr wrote:
> > [*] We end up merging "svn copy /branch/A /branch/B" from branch
> > to trunk as "svn copy /branch/B /trunk/B" while it should be
> > "svn copy /trunk/A /trunk/B" plus merging any additional textual edits
> > made in /branch/B since its inception into /trunk/B.
> > Right now, edits made to /trunk/A after branching do not make their
> > way into /trunk/B in the merge result, which is wrong since B is
> > supposed to be a copy of A on trunk, too, but ends up not being a copy
> > of /trunk/A. And it's even worse with moves because changes made to A
> > after branching just get dropped in <1.6. In 1.6 and beyond, we're
> > flagging a tree conflict on A, (local edit, incoming delete upon merge)
> > but we should be handling this automatically. And IIRC detecting this
> > case doesn't even work for directories right now.
>
> whoa, stsp, you sometimes have a way of writing a really complicated example
> in one huge paragraph rant.
Your diagram sums it up nicely though :)
> I admittedly do not understand every detail in
> this one... but I do have a question:
>
>
> A /trunk/A
> |
> |\_________svn copy ^/trunk ^/branch___________
> | \
> M /trunk/A (1) |
> | svn copy A B
> | A+ /branch/B
> | |
> | M /branch/B (2)
> | |
> | <--- merge ---{ |
> A+ /trunk/B (3) |
>
>
> So you argue that (3) should contain *both* the edits (1) and (2), instead
> of just (2)? It seems to me that it is impossible to know whether a user
> wants that or not!
True, there is ambiguity. There is more than one way to merge this.
> I can imagine both cases:
> - "What!? Why did it not merge the edits on /trunk/A (1)?"
> - "What!? It included all the edits on /trunk/A (1) as well?"
Does it need to be configurable? I'd imagine that merging the
edits by default is a safe thing to do. Note that e.g. Mercurial
does this by default, so there is precedence.
> I would probably have been asking the latter, *not* expecting trunk/B to
> contain (1). So operation based merges would throw me off at first.
In a huge merge, it's easier to revert a textual edit you don't want,
and which you can see in svn diff, than to find an edit which should
have happened but didn't. And which you can't tell from svn diff so
it's easy to overlook -- you may see it as part of a file being deleted
but if it's a huge file who is going to bother checking every line
for things they want to keep in the copy?
> If I got it right and you're sure about it, it seems to me like this
> situation needs some kind of conflict resolu
> * neels stops short.
We could flag a tree conflict and have the edits be applied
to the victim by default. Just like we currently schedule some
victims A+ by default to make it easy for people who want to keep
the victim. People who do not want to keep the A+ victim can just run
'svn revert victim' to unschedule it. People who do not want the
edits in the copy can just revert them. At least the edits have
been brought to their attention this way. And that's what Subversion
is supposed to do -- helping people with keeping track of changes.
Stefan
Received on 2009-07-21 16:45:14 CEST