On Thu, Aug 18, 2011 at 05:30:59PM +0200, Markus Schaber wrote:
> My idea was that directories itsself would never conflict. If there's a
> directory removed, and a new one created with the same name, it is the
> same directory, so no tree conflict. If the directories have different
> properties, then those properties conflict, and if they have conflicting
> files, then those files conflict individually. But no tree conflict.
>
> But maybe my thought is a little bit to short.
Depending on what the directories represent, this may or may not
be desirable.
Consider this example:
Two Java developers, Harry and Sally, work on different feature
branches A and B. The code base they're working on is a sales
and purchase tracking system.
Harry creates a new package called 'fruit' on branch A, which
contains classes for tracking fruit sales.
Sally creates a new package called 'fruit' on branch B, which
contains classes for tracking fruit purchases.
Both packages do serve entirely different purposes but happen to share
the same name (of course, the example hinges on the fact that there are
no subpackages which devide packages between the 'sales' and 'purchase'
categories -- but things like this do happen in real life).
Feature branch A gets merged into trunk.
Feature branch B gets merged into trunk. Now there is a tree conflict.
If we simply throw both sets of files in the different 'fruit' packages
together into a single 'fruit' directory, Sally will have a lot of fun
sorting the individual files back into different directories.
Note that this is how git, Mercurial, and maybe others behave in this
situation.
Right now, Subversion simply flags a conflict and lets the user resolve
the situation in the working copy. This is a crude user-interface but it
covers all possible resolution strategies, assuming the user knows how
to achieve the desired state in the working copy (this is often more
easily said than done!).
But I don't think subversion should enforce one particular merge outcome.
My opinion is that the user should be given a choice, and be supported
by an interactive conflict resolution prompt that shows all possible
resolution strategies:
- put all files in the same directory ("Markus Schaber's strategy")
- rename the local directory
- rename the incoming directory
- delete the local directory, replace with incoming directory
- discard the incoming directory, keep the local directory
- discard both directories
- etc... (are there any more possibilities?)
This is what I hope Subversion will eventually be able to do.
There's a ton of work left until we get there and it's not an
easy problem to solve.
However, the foundations that 1.7 provides with wc-ng are already
bearing fruit, and make progress a lot easier than it was with 1.6.
We started working on better support for local moves on trunk after
1.7 was branched about a month ago. Right now I have svn status
showing me tree conflicts such as:
$ svn status
R + C xx
> moved from alpha
> local moved here, incoming add upon update
D C alpha
> moved to xx
> local moved away, incoming edit upon update
Summary of conflicts:
Tree conflicts: 2
$
This would have been impossible to implement within a similar time
frame in the Subversion 1.6 code base.
I don't know yet how far we will get for 1.8. We probably won't be
showing the interactive prompt I described above. But there is still
a lot of time left until 1.8.0 and we'll try to make as much progress
as possible.
If you have any more suggestions or ideas, please keep sharing them.
Now is an excellent time for this. Thanks.
Received on 2011-08-18 18:13:51 CEST