Merge tracking in 1.5

As I mentioned in my previous post, the Subversion project has identified many requirements based on input from both the open source community and from the enterprise data collected by CollabNet from its customers. The requirements as well as the functional and design specifications are available on the Subversion project site.

Subversion’s upcoming 1.5 release is scheduled to deliver the core merge tracking feature with subsequent releases likely extending this. Fundamental to all merge tracking related functionality is the functionality to automatically record what change sets have been copied, or merged, where. On top of this, the 1.5 release will deliver the following functionality:

  • Repeated Merge

One of the most frequent definitions of what merge tracking means is the concept of dealing with repeated merges. The requirement is to track which change sets have been applied where, so that users can repeatedly merge branch A to branch B without having to remember the last range of revisions copied. This would also track change set cherry picking by users, so that Subversion won’t accidentally re-merge change sets that are already applied.

  • Cherry Picking

Cherry picking is the merging of one or more individual changes from branch A into branch B (as opposed to the merge of all previously unmerged changes). Subversion will provide a way to indicate that the change(s) have been merged into branch B. Such merging must be supported in multiple different directions, for instance if a release branch B is created by copying the trunk, both forward port changes made on branch B into the trunk and backport changes made on the trunk into branch B without confusing the merge tracking algorithm.

  • Record Manual Merge

Recording manual merges allows change sets to be marked as merged without having used the ‘svn merge’ sub command to create the defined target revision. This could be to mark a situation when there is no merge tool for the file type and a user merged the changes manually. Also, it should support merge tracking of a change set which is sufficiently different when ported to a different branch that the use of ‘svn merge’ is no longer appropriate.

Example scenarios requiring this functionality include (a) the actual change you want to apply to the branch has no overlap with its incarnation on the source branch but is conceptually equivalent, (b) only a subset of a change set warrants application, and (c) the branch content has drifted far enough apart to make automatic merging impossible (for instance, because it would generate excessive merge conflicts).

  • Rollback Merge

The ability to undo a merge and/or the associated tracking meta data, regardless whether the merge is the result of an automated or manual merge.

  • Block/Unblock Change Set

Subversion will be able to protect revisions from accidentally being propagated elsewhere.

  • Automated Merge

Subversion will have the ability to automate merges and support interfaces for resolving conflicts and other errors.

Tagged with: , , , , , , , , , ,
Posted in Subversion
9 comments on “Merge tracking in 1.5
  1. Matt S Trout says:

    Is there a reason why subversion has gone to all the trouble of re-implementing all this stuff in core when it was already available in the excellent and free SVK client? Seems like a lot of effort to produce the same wheel that many of us have already been using for a couple of years …

  2. Casey MacPherson says:

    I think you answered your own question. Providing something in core gives this excellent feature set to everyone regardless of a client. Merging really seems like it should live in the core source control system and not as some afterthough in an external client.

  3. svk is not a Subversion client, it is essentially an entirely separate version control system that just so happens to use parts of Subversion to implement its features. From the svk homepage:
    “svk is a decentralized version control system built with the robust Subversion filesystem. It supports repository mirroring, disconnected operation, history-sensitive merging, and integrates with other version control systems, as well as popular visual merge tools.”
    svk is a great tool, but telling Subversion users they have to use it is not an acceptable option. Subversion needed these features to be added to th core.
    Mark

  4. Bob says:

    People definitely don’t want to depend on a single client to provide merge capability nor to be aware of merges done using other clients. A generic core feature is the right answer so that everyone equally benefits and has access. Each client has its unique place, and svk certainly has its, but certain functionality needs to be available across all clients and merge tracking fits that bill.

  5. Any hints when Subversion 1.5 is going to be available? This merge functionality does seem to be very useful.

  6. The 1.5 release is targeted for late summer. Generally the GA release will be about 6-8 weeks after the first release candidate is issued and it is not at that point yet.

  7. kirill says:

    Are you going to make any public comments to Linus Torvalds’ rather rude and aggressive speech he made at Google conference?

  8. Auke Jilderda says:

    Ah well, there is not much to say. I didn’t feel a need to respond but, since you ask, don’t mind sharing my personal opinion.
    Linus Torvalds has a name to uphold when it comes to being blunt and opinionated but when everything is said and done, I think it boils down to Linus Torvalds and/or the Linux kernel team having wants or needs that are so particular to them that they feel it worthwhile to develop and maintain a version control system completely tailored to them. The vast majority of projects out there, however, want to focus on their project and have less esoteric wants or needs and consider Subversion to be much better suited to their needs than Git, let alone maintaining their own version control system. One can easily see this confirmed in the amount of usage and the adoption rate [1].
    (Note: Judging from the summary in the blog post SlashDot mentioned [2], I expect I can spend my 70 minutes better elsewhere than to watch the full talk so I have only seen the statements in that post.)
    1. http://subversion.open.collab.net/subversion-adoption.html
    2. http://codicesoftware.blogspot.com/2007/05/linus-torvalds-on-git-and-scm.html

  9. Sohail says:

    What functionality does the new merge tracking offer over svnmerge.py? I am currently advocating not using svnmerge.py on account of it not being as flexible as svn merge (w/o merge tracking).

Leave a Reply

Your email address will not be published. Required fields are marked *

*