It's all about the answers!

Ask a question

Analyzing change set dependency


Anders Truelsen (1622020) | asked Apr 14 '11, 8:46 a.m.
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

3 answers



permanent link
Geoffrey Clemm (30.1k23035) | answered Apr 14 '11, 9:48 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Just accept the change set, and see what the conflicts look like.
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

permanent link
David Lafreniere (4.8k7) | answered Jun 25 '14, 3:34 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
I agree with what Geoffrey said. Just accept the change set, and see what the conflicts look like.
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

permanent link
Anders Truelsen (1622020) | answered Jun 26 '14, 4:02 a.m.
 Hi David

We're on 4.0.6 and I'm thrilled by the merge improvements.
We cannot move to 5.0 as don't have a SQL Server 2012 and 2014 isn't supported by 5.0 though.

I still think some visualization of the changeset dependency would be useful. 
From a long history of changes I'd like to have an indication on exactly which changes I should accept to get the cleanest merge.
I imagine something along these lines: 
  1. Accept cs42 -> You've got a gap, this changeset depends on changes in cs38
  2. Accept cs38 as well -> You've got a gap, this changeset depends on changes in cs27 and cs29
  3. Accept cs27 and cs29 -> You've got a gap, cs29 depends on cs7, cs9, cs17, cs21 and cs26
At this point I'll then unselect cs29 choose to fill in the gap for that changeset to complete my merge.

What do you think?

/anders

Comments
David Lafreniere commented Jul 02 '14, 10:36 a.m. | edited Jul 02 '14, 11:05 a.m.
FORUM MODERATOR / JAZZ DEVELOPER

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>


David Lafreniere commented Jul 02 '14, 11:03 a.m.
FORUM MODERATOR / JAZZ DEVELOPER

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>


David Lafreniere commented Jul 02 '14, 11:04 a.m. | edited Jul 02 '14, 11:04 a.m.
FORUM MODERATOR / JAZZ DEVELOPER

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>


David Lafreniere commented Jul 02 '14, 11:04 a.m.
FORUM MODERATOR / JAZZ DEVELOPER

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.

Your answer


Register or to post your answer.