Version 13, last updated by Andy Singleton at July 26, 2011 19:50 UTC

Decrease font size Decrease font size

Increase font size Increase font size

Print this page Print this page

Home

This project will hold the plan and tickets for fixing Subversion merge.

You can see the overall structure of this plan in Andy's blog article about It's Time to Fix Subversion Merge

Contributors should sign the Apache Contributor License Agreement, so that we can commit our code to the Apache svn project. ou can read more about the CLA and how to file one here: http://www.apache.org/licenses/#clas

Goals

  • Eliminating the need for "reintegrate" options and related user confusion.  "merge <from source>" should get all un-merged changes from any branch.
  • Foreign merge.  This will lead to fork and merge workflows that will be very useful for both open source and corporate development.
  • Handling many more more cases of cross-branch merging where changes cannot be selected from a single revision range..
  • Better handling for tree changes
  • Continuous improvement that involves more contributors and new merge algorithms

Proposed Steps

  1. Make a stub "svn newmerge" command that is a copy of "svn merge"
  2. Add restrictions so that we do not support subtree merge.  Remove "depth" and "reintegrate" options
  3. Modify this command so that it uses information in a merge_history file at the root of each branch, and does not use merginfo.  At this stage, we can use the same data and data format, but just write it into a different place.
  4. Convert the merge_history to an extensible data format, something like json, so that we can add information without causing problems.  We need to design both the merge graph format, and the extensible data format inside it.
  5. Add information to merge_history after each merge to describe the exact merge - source branch, revision, and changes made to resolve it.  Include the merge_history from the source branch as part of a merge history graph or tree.  So, we should have the complete merge graph going back to some common ancestor.
  6. Modify branch so that it adds the origin in merge_history.  We'll need that to make the history complete
  7. Improve the one-URL "<newmerge <from source>" command so that it works correctly when merging to trunk (the former reintegrate option) and updating branches from trunk, without specifying any other options or instructions.
  8. Open up development to other contributors.  The data structure and algorithm should be documented.
  9. Support foreign merge.  Change all branch and revision information to refer to server_id + branch + revision.    Figure out how to do "clone" of repository or subtree, including an initial merge_history entry showing the origin.
  10. Improve the one-URL version for "svn newmerge <from source>" so that it accurately gets changes from source, even if it cannot get those changes from a single revision range.
  11. Modify the newmerge command so that it does not support the two-URL format
  12. Improve tree change handling by checking and fixing the cases where merges need to follow a move operation.  Insert move operations into the merge_history when found.
  13. Fix problems of tree changes and duplicate file insertions, even if the user has not entered a move operation.  During a merge, pattern match files and directories.  Where a match is found, either add a "move" operation, or record some other information in merge_history
  14. Clean up merge_history so that each branch of the merge_history stops when it gets to a common ancestor in a different branch
  15. Optional cleanup:  Force "merge" to execute "newmerge" if merge_history is found.  Script to translate merginfo to merge_history.
  16. Speed enhancement.  The iterative merge cases will be slow in the current architecture.  We can upgrade the API and the "stash" capability to make them faster