On Tue, Aug 24, 2010 at 08:59:32AM +0100, Julian Foad wrote:
> On Tue, 2010-08-24, Stefan Sperling wrote:
> > On Mon, Aug 23, 2010 at 06:40:39PM +0100, Julian Foad wrote:
> > > You seem to be talking only about the case where the (locally added)
> > > target is the root of the whole merge, and saying that lack of ancestral
> > > relationship between the source node and this target node doesn't
> > > matter. Maybe the user performing the merge is fully aware of what
> > > he/she is doing, which is fine in this simple case. But what about the
> > > general case, where the modification to a locally added node may be
> > > somewhere deep down in a merge that's supposed to be a simple automatic
> > > merge?
> > I don't think locally added nodes somewhere deep within the merge target
> > are affected by this change. Those should be handled by the regular
> > tree conflict logic. The change only affects the merge target root,
> > which can now be a locally added file or directory. Previously,
> > Subversion just errored out on locally added merge target roots
> > and didn't merge anything at all.
> Oh, OK! That makes sense then.
I've thought about this a bit more, and am now convinced that there
is in fact a use case where your policy distinction makes sense. :)
If users do automatic merges, those merges can be pretty complex and could
contain several merge steps. At each step, the merge command would be run
to merge a change into a root below some logical "merge master root".
So each individual merge is run with a different root. In this case,
users might expect a merge into a locally added node somewhere below the master
root to raise a tree conflict, because they may not be able to tell in advance
whether a series of merges will end up using an added node as merge target.
But this is a very narrow use case, and Subversion behaves far worse in other
tree conflict situations (e.g. deleted directory vs. deleted directory is
still not recognised). And I would suggest to people who run into this
situation and expect a tree conflict to review their branching/merging
patterns and simplify them to avoid this situation.
Received on 2010-08-24 12:30:24 CEST