I agree that they want the entries in the directory to be "collapsed" together. Thinking closely about it, though, if we collapse things into the value in OTHER, it is actually better overall.
The reason is that the value then propagates. So if I do:
cd branch1
bzr merge ../branch2 # I now get branch2's file-id for NAME
bzr commit -m "resolved some stuff"
cd ../branch2
bzr merge ../branch1 # No conflicts, because we are using the same file-ids.
However if you do the opposite:
cd branch1
bzr merge ../branch2 # Merge, but keep branch1's file-id for NAME
bzr commit -m "Include branch2's changes."
cd ../branch2
bzr merge ../branch1 # Conflict *again*, but again resolve in favor of THIS
bzr commit -m "bring in branch1"
cd ../branch1
bzr merge ../branch2 # Conflict *again* ...
I ran into this when working on "annotate". If in doubt, take "OTHER" because that "spreads" it to everyone, and eventually everyone agrees. If you always resolve in favor of THIS, then everyone always disagrees.
I agree that they want the entries in the directory to be "collapsed" together. Thinking closely about it, though, if we collapse things into the value in OTHER, it is actually better overall.
The reason is that the value then propagates. So if I do:
cd branch1
bzr merge ../branch2 # I now get branch2's file-id for NAME
bzr commit -m "resolved some stuff"
cd ../branch2
bzr merge ../branch1 # No conflicts, because we are using the same file-ids.
However if you do the opposite:
cd branch1
bzr merge ../branch2 # Merge, but keep branch1's file-id for NAME
bzr commit -m "Include branch2's changes."
cd ../branch2
bzr merge ../branch1 # Conflict *again*, but again resolve in favor of THIS
bzr commit -m "bring in branch1"
cd ../branch1
bzr merge ../branch2 # Conflict *again* ...
I ran into this when working on "annotate". If in doubt, take "OTHER" because that "spreads" it to everyone, and eventually everyone agrees. If you always resolve in favor of THIS, then everyone always disagrees.