On Jan 15, 2013, at 8:38 AM, Julian Foad wrote:
> I think the main point is you need to understand that
>
> "svn merge" doesn't calculate the union of two sets of nodes, it
> combines
> two sets of *changes* that have been made since a common starting
> point.
>
> You might want to read the section on merging in The Book <http://
> svnbook.red-bean.com/>.
I do understand that, and I did read that.
In this case the common starting point is revision zero, i.e. the
initial empty state of the repository. I do understand that most
Subversion merge use cases have a non-empty common starting point,
but this case does not.
You can excuse Subversion's behavior by saying the two directories
named D2 were created independently, so they can't be merged, but
that doesn't make the current behavior useful. Anyway the two
directories D1 in my testcase were also created independently, yet
Subversion was able to merge them. Is it really right that
independently created directories with identical sets of child names
can be merged, but independently created directories with disjoint
sets of child names cannot be merged?
On Jan 14, 2013, at 10:03 PM, Ben Reser wrote:
> Looks to me like you're using the merge command wrong.
>
> 1) You're using the sync merge format of the 1.7.x merge command,
> however the two branches you're merging (B1 and B2) have no common
> ancestor. Since B2 was copied from T1 which you independently
> created, there's really no way for the command to know what to do.
> The fact that it does anything can be considered a bug
I would consider it a bug that svn merge didn't recognize that the
initial empty state of the repository was the common ancestor, so it
needed to merge all the changes on both branches. You might disagree.
> 2) If what you're really intending to do here is a cherry-pick merge
> of the changes that were made on B1 (adding A and test1.txt) then....
Isn't it strange to you that you tried a bunch of variations and some
of them worked and others didn't? It seems strange to me. Maybe
that's because I don't understand Subversion well enough to see a
pattern in what works and what doesn't.
> Your example use case seems so far from any realistic
> scenario that it's hard to envision what you're actually doing here.
I didn't want to distract you by providing information about anything
other than the boiled-down test case, but maybe that was a mistake.
The real-life situation involves migration from ClearCase using
ClearVision's migrate2svn tool. Because of the way that tool works,
elements which were the same object in ClearCase can be created
multiple times independently in Subversion, without telling
Subversion that they are related, other than having the same name in
different branches. In addition, that tool can create partially
populated branches which then need to be merged together to create a
fully populated branch. It was that final merge that failed with
tree conflicts. So it really is a realistic scenario if you think
migration from ClearCase to Subversion is realistic.
> I can understand the argument that maybe we should handle this
> directory creation conflict a little more gracefully, but it does seem
> to be a legitimate tree conflict.
If one of the two things being merged created a directory and the
other deleted the same directory, I would call that a tree conflict.
But I don't see how two adds to a directory can be a conflict; if the
names being added are different, there is no conflict. If the names
being added are the same, merge the children. However, I don't
understand Subversion's definition of tree conflict. http://
svnbook.red-bean.com/en/1.7 doesn't define it, and the example it
gives involves rename vs. edit conflict, not add vs. add conflict.
I don't really want to have an argument. I am just trying to point
out that Subversion's behavior is not useful in this case. I am also
not sure Subversion merge is behaving consistently in all cases.
It's the Subversion development community's choice whether to improve
the behavior or leave it like it is.
And before I forget, thank you both for the quick and thoughtful
responses.
--Dave Moon
Received on 2013-01-15 15:18:54 CET