On Tue, May 01, 2012 at 10:02:10AM +0200, Stefan Fuhrmann wrote:
> Hi Mergeans,
>
> One of main sources for merge conflicts in SVN
> is its inability to follow renames. Philip and
> (the other) Stefan already made some attempts to
> solve that issue on the client side:
>
> http://svn.apache.org/repos/asf/subversion/branches/moves-scan-log/BRANCH-README
>
> After some discussion on the list and with Julian
> on IRC, I think I found the following workable
> model and I would like to start implementing it
> on some branch.
I skimmed this message the day you sent it.
I felt that something was wrong, but I couldn't put my finger on it then.
Now I just had one of those light-bulb moments in the shower so I
can finally answer :)
Overall this is an interesting idea and there is nothing wrong
with specifying a revprop format for the purposes you outline.
However, this bit is worrying me:
> * "continue" and "ignore" do not affect the merge of
> tree changes. However, the merge might use them to
> resolve tree conflicts. But that part will not be
^^^^^^^^^^^^^^^^^^^^^^^^^
> specified here.
^^^^^^^^^^^^^^^
Why not? I believe you are avoiding the real problem.
On the moves-scan-log branch I too started by enhancing the amount of
information available to the client. Not by adding information to a revprop,
but by scanning the log for moves. But that difference is a small technical
detail. Either way we'll run into a dead end. It doesn't matter where new
information comes from. We could even just ask the user. The point is that
once I had this information available I found that we are severely lacking
ideas, design, and infrastructure to make use of this information.
I think we need to take a big step back and decide how we really want
tree conflict resolution to work. We need to define behavioural aspects.
We need to declare what possibilities we are going to provide to our users
during interactive and non-interactive conflict resolution.
We need to map conflict cases (there are a *lot*) and decide how we want
to handle each one. We need to list options we want to offer users to help
them with making decisions, and once we have all that, *then* think about
how we want to implement all of this.
As I briefly mentioned in
https://svn.apache.org/repos/asf/subversion/branches/moves-scan-log/BRANCH-README
I think we need to design a new subsystem of Subversion that is focused
purely on resolving conflicts. The current situation where tree conflicts
are handled during editor drives has too many limitations and overcomplicates
the system because of poor separation of concerns between subsystems.
This new resolver should be designed based on the behaviour we would like to
see during conflict resolution. (And, BTW, not the existing conflict-store
spec in the wc-ng notes which wasn't designed with any actual behaviour
in mind either.)
I am happy to know that new resources are available to enhance 'merge'.
I am very happy with the work Julian has been doing to make 'merge' easier
to use by makeing the --reintegrate option unnecessary.
But I am not very happy with your proposal and I think it would be a waste
of our time to start implementing something like this right away without
any substantial plan on how exactly it is going to be used to resolve
tree conflicts.
Defining new data models won't help unless we have a good understanding
of what we want the conflict resolver to do with the data. I would prefer
if those trying to fix merge would think more about tree conflict resolution
than anything else. This is a huge problem nobody will solve on their
own so we really need to work together on this to solve it.
Does that make sense?
