If you have previously read the Overview of the CollabNet Merge client, you may have seen mention of the fact that the merge client is extensible to support different types of merge input. CollabNet has developed one such extension and that extension allows you to merge changes based on artifacts in our issue tracking system. For the sake of brevity, we will refer to this as the Change Set client and it is included by default with the CollabNet Merge client.
Everyone has their own definition of a change set. So let's start by defining what we mean when we say change set. In the context of this extension to the CollabNet Merge client, a change set is all of the Subversion revisions associated with a specific logical change. In this case, that would be a single Project Tracker or CollabNet SourceForge Enterprise Tracker artifact. When a user performs a Subversion commit (using any Subversion client) they can associate it with a Tracker artifact by referencing the artifact(s) in the commit message. A hook running on the Subversion server links this commit with the artifact. The hook can optionally require that an artifact is referenced in order to allow the commit.
The list of commits that have occurred for a given artifact can be seen from the UI either in Eclipse or the web browser. The artifact serves as an audit trail for all of the activity that has occurred around the issue, including approvals and signoffs, development activity, tests etc. Additionally the artifact might be linked with other related artifacts. For example a requirement artifact might be linked to one or more development artifacts to implement the requirement.
The purpose of the Change Set client is to broaden this link between Subversion revisions and artifacts by allowing you to perform merges in Subversion by specifying the artifacts you want to merge, rather than the revisions. This approach is more in line with the workflow and mental model for most individuals and organizations than a revision is. Consider this example:
You are supporting several releases or variants of your software. A defect is reported and entered as an artifact and assigned to a developer. In this case the developer happens to use Eclipse and the CollabNet Desktop. They receive notification of the defect right within Eclipse and open it up to view the details. They see that this is something they need to work on right away so they activate the task in Mylyn. Mylyn closes all of the editors they had open for the previous task they were working on so the developer can focus on the task at hand. The developer opens and edits the files they need to change for the task. Mylyn creates a Subversion change set for this task in the Synchronize view (due to the integration between Mylyn and Subversion via the CollabNet Desktop). The other changes the developer had been previously working on are nicely stashed away in different change set(s) for the other tasks they were working on. When the developer completes their work, they can commit the changes from the Synchronize view. Mylyn has entered a default commit message with the proper association to the artifact they were working on. The developer adds some additional details and commits the change to their Subversion repository inside CEE or CollabNet SourceForge Enterprise. At this point, the hook script runs and associates the commit(s) with the artifact. Perhaps the developer is done, perhaps they have some more work to do and wanted to do an initial commit to save what they had done. Regardless, at some point the developer is done, and all of the commits they have done have been associated with the artifact. The developer updates the artifact from within Eclipse, sending it on to the next stage of the lifecycle.
To continue the story, let's skip the QA and verification phases and just assume they have happened. It is quite possible that those stages involve branches and they might use the change set client to merge those changes. For the sake of this description, we really only need to use the client one time to illustrate its usefulness. The artifact has passed QA, meetings have been held with the change control board, and it has been decided that this fix needs to be backported to all of the existing releases/variants that are supported. Let's examine how someone would do this using plain Subversion, and how they would do it using the Change Set client.
Plain Subversion Merge Client
I am not going to illustrate this with screenshots, but the user would have to open the artifact(s) and record all of the commits that took place for the artifact(s). They would then run the merge client and enter/select that list of revisions to merge those changes to the branch. It is not too hard to do on a small scale, but it can get error-prone and time consuming as the number of revisions and branches increases.
Change Set Client
So lets assume the user has this change set client. How does that help them do the merge? First, let's assume they already have all of the branches checked out that they are managing. They could do this one branch at a time, and then switch to the next branch and repeat, but this client will also allow them to merge the changes to all of the branches at the same time. Let's do that. Select all of the projects for all of the branches, right-click and choose Team > Merge.
The merge wizard comes up as shown above. We have selected the change set based merge in the list of inputs, after which, we can click Next.
On this screen the user just needs to enter the path they are merging from, such as /trunk and the list of artifacts they want to merge. There is a Select option that allows you to choose from the list of artifacts you have in your local task list.
The artifacts do not need to be in your task list to merge, just to select. If you know the id's you can also just type them. The assumption is that in most cases the user probably would know the artifacts they are merging -- after all, part of the point of this exercise is that the artifact ID is an easier abstraction to work with. Once the list has been entered, the user clicks Next. At this point, some work happens. The client contacts the server and retrieves all of the Subversion commits that have occurred for the list of artifacts. It then retrieves the Subversion information and presents it to the user as a final confirmation.
By default, all revisions will be selected to be merged, but the user can deselect one or more of the revisions if necessary. The user can click Next to review the merge options (see the Overview for details) or they can just click Finish.
The merge process runs and merges each of those revisions to each of the selected branches. If the user indicated they wanted to resolve conflicts along the way, they will be prompted to do so as the conflicts are encountered. When the user is done and has possibly built and tested the changes, they can be committed to each of the branches. If the same artifact ID is referenced in the commit, the fact that it was merged to the branch will be recorded in the artifact along with all of the other activity -- completing the cycle.
Refer to the Overview of the Merge Client for details on post-merge usage of the client.
China
Korea
Japan
Korea
Japan