Re: Subversion merge creates bogus tree conflicts

David Moon wrote:

> On Jan 15, 2013, at 12:06 PM, Julian Foad wrote:
>> but I at this point I still think the use case is invalid.  Or, put another
>> way, the use case is certainly something people might want to do from time
>> to time but the "merge" command is not the tool to do it.  Rather it
>> requires some manual steps to set up a starting point from which "merge"
>> can then do the rest.
>
> Fair enough, but there is no clue in existing documentation what those manual
> steps might be.
>
> As a user, I think it would be easier if the special fixing up had to be done
> after the merge had reported conflicts rather than before.  But there don't
> seem to be the same svn resolve features for directory merging as for file
> merging.

Yup, this whole area needs better documentation and even more importantly better design and implementation.  Anybody reading this who might be able to help in any way, please get in touch!

>> Two adds of different names to the same directory do not conflict.  The
>> conflict you saw is on attempting to add a file into a directory ('A')
>> that didn't exist on the target.
>
> I am sure you are correct, but it wasn't clear from the output of svn merge
> and svn status.  This can be regarded as another bug report: the error messages
> for tree conflict (in svn 1.7.8, I don't know about newer versions) range
> from misleading to incomprehensible.  Designing good error messages is not an
> easy problem, as I well know myself, so please take that as a potential area for
> improvement, not as criticism.

OK, feedback taken.

> Hmm, I wonder if the directory not existing on the target means this is actually
> a simple bug, not really some complicated problem with merging.  Why wasn't
> the parent directory of a file being added created automatically, as if svn
> merge took a --parent argument?  When would that be harmful?

It's very complex -- in general (different merge scenarios) the delete might have been a conscious user action committed in the target branch, and might be a move away rather than a plain delete, since svn still lacks move tracking.  We can't assume that just recreating the dir is the right thing, although it should be offered as an option in the conflict resolver.

> But then, what does the "local add, incoming add upon merge" error
> mean if not a conflict of adding different names to the same directory?  Sorry I
> don't have a simple test case to provoke that error.

It means the thing (at a specific path) didn't exist in the "old" side of the incoming change, and is being added by the incoming change of the merge, and also exists in the target already (apparently having been "added" since it wasn't present in the assumed common ancestor).

> Again, I don't need a solution myself.  I only reported this as a way of
> giving back to the Subversion community by suggesting an ease of use
> improvement.

Thank you; I do appreciate it takes time and effort to do so, and it is valuable to us.

- Julian
Received on 2013-01-15 19:30:47 CET