Analyzing change set dependency
3 answers
If you decide you don't want to merge now, just suspend or discard the
change set.
Cheers,
Geoff
On 4/14/2011 8:53 AM, atruelsen wrote:
Hi Folks
Is there anyway to determine the dependency relationship for a given
change set without actually deliver/accepting it?
Basically I'm trying to assess the merge effort prior to actually
performing it.
regards
/anders
If you decide you don't want to merge now, just suspend or discard the change set. This will also let you know if gaps are involved. It can also let you get an idea of how much merging is required if you want to merge just the selected change set(s), and will also give you an idea of how many change sets fill the gap (which also may result in conflicts after accepting). This all depends on which RTC version you are using however.
In RTC 4.0.5 we delivered additional support when trying to accept change sets which have a gap (often encountered when trying to backport fixes). In a very brief summary of the feature, when you accept change sets with a gap, you can now follow a gap workflow that accepts one change set at a time and, for change sets that contain gaps, creates a new change set (with aided traceability), that contains the equivalent changes. This means users will not have to accept the change sets 'as a patch'. Applying change sets as a patch has limitations compared to the new workflow (as discussed in the article below).
This feature is summarized in the RTC 4.0.5 'New & Noteworthy' page: https://jazz.net/downloads/rational-team-concert/releases/4.0.5?p=news#scm-improve-usability-405-m1
Below are some videos which show this feature:
-Accepting multiple change sets with gaps in the RTC 4.0.5 client for Eclipse IDE: https://www.youtube.com/watch?v=28raag5RdzU
-Accepting a change set with a gap in the RTC 4.0.5 client for Eclipse IDE: https://www.youtube.com/watch?v=TucVu_BgB7E
In RTC 5.0 we added a "fill the gap" feature where the change sets that fill the gap are shown to the user, allowing them to either accept all the change sets or to continue with the gap workflow that was available in RTC 4.0.5.
This feature is summarized in the RTC 5.0 'New & Noteworthy' page: https://jazz.net/downloads/rational-team-concert/releases/5.0?p=news#eclipse-fill-gaps
The classes that are involved for filling the gap include (available in RTC 5.0):
client side: IWorkspaceConnection.findChangeSetsToAcceptToFillGap(...)
server side: IScmQueryService.findChangeSetsToAcceptToFillGap(...)
Both features are explained in detail in the "Improved Gap Handling for SCM" article: https://jazz.net/library/article/1372
- Accept cs42 -> You've got a gap, this changeset depends on changes in cs38
- Accept cs38 as well -> You've got a gap, this changeset depends on changes in cs27 and cs29
- Accept cs27 and cs29 -> You've got a gap, cs29 depends on cs7, cs9, cs17, cs21 and cs26
Comments
I agree it would be nice to have some visualization of the change sets that fill the gap. However nothing can be done in 4.0.6 to support that. We released some pretty complicated changes of the internal workings of SCM in 5.0. These changes enable a few features, one of which was the ability to easily identify the change sets that fill the gap (which was also added for 5.0).
Also, the example you provided in steps 1-3 doesn't actually work like that in our SCM model. In step 2 for example, if we identified that CS38 depends on CS27 and CS29, (i.e. they are the change sets that fill the gap), then when trying to accept those we would not get another gap exception. They would just accept cleanly since those are the change sets in the gap, otherwise we would include 'all' the change sets in the gap. For example starting from the top, if you accepted CS42, then it really does depend on also accepting CS7, CS9, CS17, CS21, CS26, CS27, CS29 and CS38, since those are the change sets that fill the gap.
<continue reading below>
Also, the use case where the end goal is to reduce the merge effort sounds a little strange to me personally, or at least I have not heard of that request specifically.
Here's some of my thoughts on that:
In general, each change set tends to represent a different defect fix or new feature, and is often associated to a corresponding work item (Note: this is a little simplified for this example). So if you are accepting a change set in the effort to accept Feature X, a gap exception 'could' occur, allowing us (in 5.0) to see that it depends on other change sets, say Feature A, B and C and Defect Fix Y and Z. At this point, the common practice is to make an executive descision as to which other features or fixes we want to also be included in the accept or back / forward port. So if you only want Feature X, you cannot accept any of the change sets in the gap, otherwise you will also be bringing in Features A/B/C or Defect Fix Y/ Z. If you decide you also want to bring in all the other features and fixes too, then you can accept them all (and you will NOT get a gap exception).
<continue reading below>
The other more rare case would be to decide at that point you want Feature X and and a subset of the other stuff, say Feature C. Since you made the decision, it doesn't matter how complicated the merge is, it must be done... So you select what you want, choose to 'not' fill the gap, and continue merging in the Gap editor which was delivered in RTC 4.0.6. However we urge anyone who does fill the gap or cherry-picks from the change sets in the gap, to ask themselves why was the decision to accept or back/forward port those features / fixes was not done before hand (i.e why were they not in the initial selection in the first place?).
<continue reading below>
Also, the most common use case I've seen for completely filling the gap, would be cases in which the user wants to do something quick and temporary, without flowing those changes to any development/integration streams. Ex: If developerA wants to review a feature that developerB was doing, developerA can change the flow target of their repository workspace to developerB's repository workspace, they can then accept the change sets for that feature (or without changing flow targets, perhaps accept change sets directly from a work item). If there are gaps, they don't care what other features or fixes get brought in, they just want to accept everything so they can get in a state which they can compile everything and test out the feature they want to test, once they are done, they likely will discard all the change sets they brought in.