Hi all,
I'd like to work on adding support for auto-resolving tree conflicts
with incoming moves during updates and merges, and also local moves
during merges. This builds on the efforts we made to resolve tree
conflicts involving local moves during updates in Subversion 1.8.
I've discussed some of my ideas before and during the hackathon week
with several people (e.g. Julian, Branko, and Stefan2), mostly in
private conversations. It's now time to present my ideas to dev@.
I know that several people are already attacking these problems from
several angles. Most ideas I've heard from others revolve around how
to transmit move information from/to the server and how to store it
in the repository filesystem. I'd like to put my main focus elsewhere,
to fill in an important missing piece of the puzzle:
What will a Subversion client do with information about incoming
moves when trying to resolve tree conflicts?
My goals include research into ideal behaviour during conflict
resolution, as well as design and implementation. I plan to use the
use cases we collected during Subversion 1.6 development as a starting
point: https://svn.apache.org/repos/asf/subversion/trunk/notes/tree-conflicts/use-cases.txt
I've recently update these notes to describe the current state of
things, as of Subversion 1.8. I plan to continue updating the file
as things progress.
My current plan is to try to implement support for resolving each use
case one by one, following the current use case numbering. Since use
case 1 has already been implemented for Subversion 1.8, I will start
with use case 2 and work my way down the list from there.
I will probably use one feature branch per use case, and merge to
the trunk whenever a stable set of changes is ready. This approach
fits well into the proposed branching/merging model for Subversion 1.9
and beyond, as discussed at http://svn.haxx.se/dev/archive-2013-06/0243.shtml
Of course, collaboration on any of my branches is very welcome!
Note that, for now, I am aiming for a complete client-side
implementation, leaving the RA and server-side bits for others
to fill in. I plan to lift code from the moves-scan-log branch
into the conflict resolver, so the conflict resolver can detect
incoming moves via a heuristic which scans the revision log for moves.
I will ensure that any future developments in the RA layer and on
the server can be plugged into the resolver instead when ready.
The code actually resolving conflicts will receive information about
incoming moves but won't care about how that information was derived.
I believe scanning the log works to a good degree of accuracy.
It is the same idea used by tools such as TruMerge
(see http://trumerge.open.collab.net/).
It can also serve as a backwards-compat layer when talking to
Subversion 1.8 and older servers, regardless of any server-side
enhancements made in future Subversion releases. Also, the code for
scanning the log has already been developed, and can now be
forward-ported into the current conflict resolver implementation
(or we can move it into the actual svn_client_log() code to be
optionally triggered there -- I'm not quite sure about that yet,
but this is an implementation detail not worth discussing right now).
There is a possibility that my work on this project will be funded
by a customer for several months. The customer understands that
features will only be designed and developed in consensus with the
Subversion community, and that I cannot make unilateral decisions
about the content of an official Subversion release. I will act as
a mediator between the community's requirements and the customer's
requirements. This situation is very similar to the implementation
of initial tree conflict detection for Subversion 1.6. At that time,
a collab.net/elego customer supported Steve Butler and myself with
funding. So this isn't an unusual situation. But I want to be open
about the potential funding to avoid any confusion about my motives
(not that I expect anyone to be surprised about my continued interest
in tree conflicts :)
The customer would like early access to the features developed as
part of this effort. I think this is a great opportunity to get
real-world testing of new features before we decide whether to ship
them in an official release. To facilitate this early access, I plan
to create a custom 1.8.x branch in our repository as per the policy
described at http://subversion.apache.org/docs/community-guide/releasing.html#custom-releases
and ship custom releases from there to the customer. I will make sure
to avoid confusion between the official Apache Subversion 1.8 releases
and any custom releases.
I welcome any additional help and support in this area, of course,
and will continue to track and support other developers looking at
improving Subversion's support for renames in other areas, such as
the RA layer and the repository filesystem.
If you have any further questions about this project, I will gladly
answer them.
Received on 2013-06-20 12:34:23 CEST