Implement Symmetric merge with Advanced Merge Request for Subversion
Posted by Andy Singleton on 2012-03-28 09:34
I want to implement “Advanced merge request” for subversion. “Merge request” is a workflow that improves the quality and scalability of a team development process. It also makes possible “Scalable Agile” workflows where releases are continuous, or assembled at the end of an iteration. Currently, many teams are moving their code to git (and to github) so that they can use this workflow. When we finish our implementation, they will be able to stay on Subversion and do the same thing.
Until now, merge request workflow has not been available for Subversion, because Subversion merge is not very good. Merge request requires multiple merges from branch to trunk. Users who merge from branch to trunk will find that they cannot update branch, or merge to trunk again, unless they perform very specific updates at the time of each merge. The merge and update sequence is too complicated and unreliable for us to recommend to most of our users. These operations also take longer than equivalent git operations.
In the last few weeks, Julian Foad of WANdisco has fixed many of the problems by implementing “symmetric merge”. This is a Subversion merge variant which correctly handles most of the cases of merging between branch and trunk. It does not handle all of the merge cases that git handles, but it handles all of the cases that we need to implement advanced merge request workflow between one trunk and contributing branches.
MERGE REQUEST PROCESS
-- APACHE MAILING LIST PROCESS
The new “merge request” process is similar to the Apache development process that I see on the Subversion development email list. In the email process:
1) A contributor makes a local working copy and edits it to make changes
2) The contributor makes a “patch” file containing the changes
3) The contributor attaches the patch to an email and sends it to the Apache development list
4) Reviewers save the patches and “apply” the patches to their local copies of trunk, and test them
5) Reviewers send email messages with discussion and “+1” and “-1” votes.
6) If reviewers like the patch, a maintainer commits the merge to trunk.
-- ASSEMBLA MERGE REQUEST PROCESS
Users of the Assembla merge request do the same thing, but with a Web-based workflow that is easier and more reliable. Here is the sequence.
1) Contributor makes a branch to hold changes, and edits it to make changes. [Client should make these branches quickly and easily]
2) Contributor commits the changes as usual
3) Contributor goes to the Web and make a “merge request” form that describes the changes and lists the source branch.
4) Reviewers see the merge request on the Web or because of an email alert. They can merge the source branch with their own copies of trunk. [We need to decide exactly how they will do this].
5) Reviewers can view the code changes, discuss, and vote on the merge request form
6) Maintainer can reject by reverting to trunk, or accept using the Web merge (if there are no conflicts), or accept by committing his copy with changes.
NEXT STEPS
1) Implement and debug symmetric merge for the apache svn client. Help Julian as much as possible.
2) Agree on the sequence of svn operations required for merge request, review, and accept. This will allows us to build the Advanced Merge Request for Subversion on the web side, and tune the clients to make those operations easier.
3) Include symmetric merge in our svn clients
4) Implement Advanced Merge Request for subversion in the Web system
5) Improve client operations and server workflow to make the process easier
FUTURE
Implement merge improvements to handle additional cases. Replace mergeinfo with a local merge_history that has more information about the history of a branch. See my proposal in this message list.
- Blog article about merge requests: http://blog.assembla.com/assemblablog/tabid/12618/bid/80158/Announcing-Advanced-Merge-Requests-for-Git.aspx
Until now, merge request workflow has not been available for Subversion, because Subversion merge is not very good. Merge request requires multiple merges from branch to trunk. Users who merge from branch to trunk will find that they cannot update branch, or merge to trunk again, unless they perform very specific updates at the time of each merge. The merge and update sequence is too complicated and unreliable for us to recommend to most of our users. These operations also take longer than equivalent git operations.
In the last few weeks, Julian Foad of WANdisco has fixed many of the problems by implementing “symmetric merge”. This is a Subversion merge variant which correctly handles most of the cases of merging between branch and trunk. It does not handle all of the merge cases that git handles, but it handles all of the cases that we need to implement advanced merge request workflow between one trunk and contributing branches.
- Wiki about symmetric merge: http://wiki.apache.org/subversion/SymmetricMerge
- Email thread: http://mail-archives.apache.org/mod_mbox/subversion-dev/201203.mbox/browser
MERGE REQUEST PROCESS
-- APACHE MAILING LIST PROCESS
The new “merge request” process is similar to the Apache development process that I see on the Subversion development email list. In the email process:
1) A contributor makes a local working copy and edits it to make changes
2) The contributor makes a “patch” file containing the changes
3) The contributor attaches the patch to an email and sends it to the Apache development list
4) Reviewers save the patches and “apply” the patches to their local copies of trunk, and test them
5) Reviewers send email messages with discussion and “+1” and “-1” votes.
6) If reviewers like the patch, a maintainer commits the merge to trunk.
-- ASSEMBLA MERGE REQUEST PROCESS
Users of the Assembla merge request do the same thing, but with a Web-based workflow that is easier and more reliable. Here is the sequence.
1) Contributor makes a branch to hold changes, and edits it to make changes. [Client should make these branches quickly and easily]
2) Contributor commits the changes as usual
3) Contributor goes to the Web and make a “merge request” form that describes the changes and lists the source branch.
4) Reviewers see the merge request on the Web or because of an email alert. They can merge the source branch with their own copies of trunk. [We need to decide exactly how they will do this].
5) Reviewers can view the code changes, discuss, and vote on the merge request form
6) Maintainer can reject by reverting to trunk, or accept using the Web merge (if there are no conflicts), or accept by committing his copy with changes.
NEXT STEPS
1) Implement and debug symmetric merge for the apache svn client. Help Julian as much as possible.
2) Agree on the sequence of svn operations required for merge request, review, and accept. This will allows us to build the Advanced Merge Request for Subversion on the web side, and tune the clients to make those operations easier.
3) Include symmetric merge in our svn clients
4) Implement Advanced Merge Request for subversion in the Web system
5) Improve client operations and server workflow to make the process easier
FUTURE
Implement merge improvements to handle additional cases. Replace mergeinfo with a local merge_history that has more information about the history of a branch. See my proposal in this message list.
Home / Developer API / Tour / Get a Project - Solutions for Bug & Issue Tracking, Collaboration Tools, Subversion Hosting, Git Hosting
Subversion newmerge is powered by Assembla.
0 Comments