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.
