1

Occasionally when I am accepting I change set I receive the following message :

enter image description here

To resolve this I apply the changes as a patch and then 'Merge into workspace' the changes Why cannot all of the change sets be found ? Is there a danger my code could become out of sync with the flow target ?

blue-sky
  • 51,962
  • 152
  • 427
  • 752

1 Answers1

1

The danger is not so much the out of sync, but the integrity of the resulting code, once the patches are applied:
You are accepting change set based on other change sets that are not delivered.
There is no guarantee that it works.

As explained in this thread:

In S1, suppose there are two change sets that have modified file foo.java: CS-23 and CS-35.
You have requested CS-35, but not CS-23.
But the state of file foo.java in CS-35 contains the changes from CS-23... So you can't get CS-35 unless you also have CS-23 (i.e. "the change set that led up to this change set").

It is ok for a developer A to not deliver all his/her change set, provided he/she delivers all change sets up to a certain point.

The warning appears in case of a partial deliver (the developer delivers B, based on change set A, but does not deliver change set A)

That might not be an issue, if there is no functional dependency (similar to git cherry-pick) between the two change sets (if B doesn't rely on code in A to compile, for instance).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I think I understand, merging the 'pending patch' will merge just the latest change set. This is ok because I just need the most up to date change set for this stream. The disadvantage is though I cannot view the past change sets which made this change set, unless of course I view in the original stream (where the change set was created) ? – blue-sky Jan 07 '13 at 14:29
  • 1
    @user470184 not only can you *not* see past change set, but if your change set only works because of a feature introduced in said invisible past change set, what you just accepted and applied in your local workspace won't work. – VonC Jan 07 '13 at 14:34
  • @user470184 it is a problem similar to `git cherry-pick`: http://stackoverflow.com/a/881112/6309 – VonC Jan 07 '13 at 14:36
  • but if said feature (by feature I'm assuming you mean new code) is available in most recent version of change set then it should work ? – blue-sky Jan 07 '13 at 14:44
  • @user470184 yes. By feature, I meant indeed new code like, for instance, a function. If you accept '`a.foo()`', but function `foo()` is defined in an *un-delivered* change set... your latest accept wouldn't compile properly. – VonC Jan 07 '13 at 14:49
  • ok but as long as I have all latest change sets within said stream then code will be up to date ? – blue-sky Jan 07 '13 at 15:03
  • 1
    @user470184 if you have *all* the latest within said stream, yes, your code will be up-to-date. The fact that you have this warning though ("Confirm Content Accept") means you don't have all latest change sets. – VonC Jan 07 '13 at 15:20
  • sorry if I'm dragging this out, im not sure I fully understand. Will I not have latest change set for each component since when I accept a change set, the accepted change set is the latest one. I may not have the change sets leading up to the latest change set, this is acceptable if the code compiles based on the change sets delivered for current stream. – blue-sky Jan 07 '13 at 15:59
  • @user470184 the fact that the accepted change set is "the latest one" doesn't mean it includes *all* the changes from the source stream. The warning you got means that it relies on other change set (that you don't have), but, as you said, it still can work. By "latest", I mean the most recent change set produced on the *source* stream. – VonC Jan 07 '13 at 16:04
  • is this not a major issue for source control then if when merging two streams I cannot guarantee that all change sets in stream i'm merging from are also in stream I'm merging to ? – blue-sky Jan 07 '13 at 16:30
  • 1
    @user470184 yes, which is why you see this warning: merging two streams in RTC means accepting change set from one stream and delivering them to the other (as I explained to you earlier: http://stackoverflow.com/a/13647350/6309): if a developer didn't have delivered *all* his/her change sets, the warning you see if a consequence. You can choose to stop the merge right there and ask for the missing change set, or you can decide it is good enough, and go on with the merge. – VonC Jan 07 '13 at 16:32
  • the missing change set, is this a change set that is 'checked in' but not delivered ? – blue-sky Jan 07 '13 at 16:35
  • By deciding it is 'good enough' , will this not cause source code differences between two streams, because this is just accepting some of the change sets in stream I'm merging from, when I should be accepting all of the change sets. – blue-sky Jan 07 '13 at 16:41
  • 1
    @user470184 yes, checked in, not delivered. As long as what you are accepting compile and includes the expected features, it is ok. The developer might not have delivered a previous change set with a feature too comple to be delivered just now. It is mainly a communication and project management issue. – VonC Jan 07 '13 at 16:52