On Mon, Jan 30, 2012 at 10:01:23AM -0500, Mark Mielke wrote:
> No merge is perfect. The situation is either complex, or it is not
> complex - and moving resolution to the private branch is a matter of
> process - not a matter of algorithm.
Where did you get the idea that conflict resolution must happen
in the private branch?
You can run --reintegrate at any time. The only requirement[*] is that,
if you merged from the parent branch, you merged a revision range which
doesn't contain any gaps. But this merged range may be empty if you wish.
If you get conflicts during that merge you just resolve them as
with any other merge.
In svnbook terms, you don't need to sync to trunk before reintegration.
There is no such requirement in the tool.
[*] Well, you're also not supposed to have local changes in the WC
and it must not be a mixed-rev WC. But those requirements don't
matter for this discussion.
> The first thing the tool can do to be genuinely useful in this
> situation, is to accept some of the responsibility of detecting
> whether or not the race is one of these "diff3 is not idempotent"
> situations, and providing automatic handling.
And this is exactly what --reintegrate does for you.
It automatically eliminates spurious conflicts. It doesn't do so by
dynamically detecting such conflicts (and how on earth would you do
that???) but it avoids input which is unnecessary and can cause such
conflicts. So the end result is the same.
> If the case has been
> hit, then --reintegrate could be used as a form of "special error
> checking" where it does the same as "merge", except in the case that
> the merge has a true conflict with any particular element of the
> change set (as opposed to a potential conflict with the end result),
> where the results of diff3 would need to be "trusted", then it could
> bail and provide the user with the information required to resolve
> the conflict locally before submission.
>
> The second thing the tool can do to be genuinely useful in this
> situation, is to allow for this check to be overridden. If I didn't
> trust diff3 - I wouldn't use merges at all. Sometimes a source
> management tool just needs to help me resolve conflicts. Especially
> with merge tracking and intelligent designer workflows, many cases
> of so called "conflicts" touch unrelated lines of code, and it *is*
> safe to complete the merge, even to the integration stream. I should
> have the ability to choose to do this, rather than race for
> submission with 100 other users.
If you don't like what --reintegrate does you're free to use 2-URL
merges instead to merge whatever changes you like and run them all
through diff3.
In fact, --reintegrate is just there for convenience and it is
entirely optional. We usually do recommend it because it is quite easy
to mess up 2-URL merges if you don't know what you're doing, and because
most people are happy with less conflicts from diff3 if they can be
avoided without any risk.
> The worst thing the tool can do is to declare that "diff3 is
> idempotent therefore it should be disabled" during --reintegrate.
> Yuck. This is a partial solution and at least as I understand it -
> it is even dangerous.
Except... diff3 is not being disabled :)
It's just not fed changes which have already been applied.
> What happens if I use --reintegrate in a
> situation that actually does require merge resolution? Will every
> situation be blocked? Or will it take --reintegrate as a license to
> overwrite results, trusting that I can do all the necessary conflict
> checking myself? I have seen nothing so far that allows me to
> conclude that architecturally, Subversion requires the --reintegrate
> behaviour. It's a short cut in providing a complete branch merging
> solution for users of the system. Somebody started work on the
> canvas, and then drafted in the last corner rather than finish it.
Well, I suppose it just seemed strange to you because you didn't
understand the purpose and mechanics of --reintegrate. And you somehow
concluded that using it must be mandatory. But it isn't.
The complete and general merge solution already existed before
--reintegrate was added, in form of the 2-URL syntax.
Granted, it is affected by the same well-known shortcomings of
Subversion's merge operation (e.g. merging through moves doesn't
work yet). But apart from that I don't see how you could want something
more general because it's already as general as possible.
Received on 2012-01-30 16:47:38 CET