Delivering these changes would introduce gaps
When the user delivers the changesets, the Eclipse client complains "Delivering these changes would introduce gaps". According to some discussions in the Forum, it suggests to use patch way or finding out dependency files to deliver the changesets altogether. These do not seem to apply to the customer's needs. The scenario is as below:
1) Suppose there are 100 changesets(the user has more than hundreds of changeset in the team)
and each changeset has multiple files.
2) When delivering some changesets, they got "Delivering these changes would introduce gaps". When checking with one conflict files, they found there are 7 changesets owning the same files(those files have dependency).
They only want to deliver 3 changesets out of the 7 changesets.(for example) and there are other files in those changesets having similar dependency files in other changesets. This means somehow the 100 changesets would have dependency as a chain.
The question is:
1) Other than deliver all the 100 changesets because of their internal chain dependecies, if they only want to deliver some changesets, is there any way to achieve that?
Another question is,
2) to avoid such chained dependent changesets(in Parallel development, file dependency seems to be unavoidable), is there any best practice the user can follow to minimize(at least) reaching to such extreme situation?
Any suggestions are highly appreciated.
2 answers
as far as i can tell, gaps happen if the user tries to deliver a specific change set and there are other change sets that are not in the stream that this one depends on. So the question is, how did the user get into that situation? I would review the reasons why and look at how to avoid it.
One reason could be the user wants to only pick a specific change set from the outgoing changes. The change set has a change to a file but there is another, older, change set that changes this file too. I have seen that if customers try to implement cherry picking. You could minimize this by only having changes to one file in the change set. It does not completely remove the issue, but makes a bit easier to deal with it. I know of a customer who created some automation to enforce this.
There are probably other reasons for this.
One built in way provided by RTC to avoid this is to suspend work. This pulls the changes out and new work would not get entangled with the other work. You could do the changes isolated and deliver them. Resuming the suspended work would result in a merge, if you have conflicting changes.
There is work ongoing to make this easier. See https://jazz.net/products/rational-team-concert/whats-happening#plan and https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&itemId=_Q5xBtqC6EeCGUsd9CqIfuw
Comments
Thanks Ralph for the prompt answers and info.
1) it is not clear why the users have hundreds of changesets in one component(they have many components).One file can have multiple dependent files in other changesets.Each changeset has multiple files and dependent on other files in other changesets which make the chained dependency. Suspend the changesets do not seem to be practical for this client because it will complain gaps unless suspend all dependent changesets. We tried to create patch for the dependent file and another patch for other files for each changeset but it is not practical here because other files may have dependent files in another changeset as well and we need to separate further which could lead to thousands of patches, hence it is hard to isolate the changes(in individual file level) and deliver.
We also think about one file in one change. It seems that different file will end in one changeset by default as the tool will put multiple files to the current changeset by default and won't ask the user to put to the different changeset. Do you have any better way to achieve this?
2)How to avoid one file to be updated in different changesets? If it is the same user, I guess we can suggest to only checkin the final version of file to the changeset to reduce the number. If the user keeps modifying the file and save, it will actually create Unresolved folder in pending change view awaiting for check-in, will that cause any problem or confusions or there is any better way to Not letting the interim version of update appearing in the pending changes view?
3) In the parallel development environment, multiple users update the same files are common. Is there any article discussing on how to do parallel development and keep the users' work in sync and not causing too much overhead in solving conflicts?I am thinking we may have each user to have own workspace, then have regular sync with the shared stream(development stream in the client's situation): accept changes from stream and solve the conflicts then check--in only final version of change and deliver to the same stream. Any advice on what is the best practice on the parallel development environment?
1) The default is to check-in files to the current change set (the one with the blue triangle in Pending Changes). The idea is any file changes you make to your current task are related to each other. They are delivered together as one unit and can never be separated. This has the advantage of ensuring all necessary changes are delivered together.
Your issue is you want to separate some of these changes and they have to be done before the change set is completed. There is no default way of making the tool always check-in files to separate change sets. That is something the developer will have to do and determine if they need to do that.
2) This may not be avoidable at all. If one developers makes a change to file 1 for task 1 and delivers, other developers may accept the change and start working on task 2 that modifies file 1 as well. Once that happens, task 2's changes will depend on task 1's changes. You cannot deliver task 2 unless you also intend on delivering task 1's change sets.
I'm not sure about your concern with unresolved changes. An unresolved change is something that has not been shared in source control. Either check them in if you care about them, undo them if you don't, or add them to the ignore file if you need them but don't want to deliver them. Developers can modify the file and save as much as they want. It's the check-in that gets recorded in source control
3) Check out Multiple Stream Development and Stream strategies with Rational Team Concert 3.x. You can also search the Jazz Library for other articles.
Thanks Tim for the answers.
According to Stream strategies with Rational Team Concert 3.x, the below discussion is on how the gap will be introduced:
===
Daniel Toczala wrote on March 23, 2011 08:51:35:
You can use a repository workspace the same way that you would use a stream, but with this model everything that I check in will become immediately visible to the rest of my teammates. Even if it doesn't compile. You also run a stronger risk of creating dependencies between work items. xxxxxx
== Does that mean it is recommended to have each user having sandbox and own private repository workspace and flow target set as development stream shared on the whole dev team, and that would reduce the potentials to introduce the gaps on the same file by different users? If the repository is the public one shared by the all team, then it could be a problem?
Daniel's suggestion is not recommended in any way. It is never good to load a repository workspace in different sandboxes because you run a high risk of desyncing one of the sandboxes. It's not horrible but you will frequently have to reload to sync your sandbox. The other issue is only the workspace owner can modify it so users can never share a repository workspace. Streams are there to act as a group workspace.
There isn't really a work flow to prevent gaps. This is the nature of change set based source control and the way RTC SCM as designed. If you intend on delivering some changes but not others, you will likely encounter gaps. The work item Ralph pointed out will help you handle this. For now, using patches would help you deliver a change without delivering another change it depends on.
Thanks Tim and Ralph for the comments.
We actually suggested to use patches but it does not seem to help in this user's scenario as their use case is too complex because. if creating a patch against one changeset, it would end up with all changesets to be in various patches because they have one or more files in one changeset dependent on another changeset(s) and they actually only want to deliver some files inside the changeset(s). Because of chained dependency, they have to separate the files into different patch and it does not work for them in practical way.
I will see if "delivering all changesets, then reverse the changes they dont want to make to the stream" will help their use case or not(discard changeset can not be done due to the gaps).
If there is a baseline which was created with intended changesets in the component and then replace the stream's component with that baseline, will that be a workaround or it could cause any potential problem in repository workspace or stream?
Regarding workitem Ralph suggested, it does not say whether and when it will be implemented which I guess it will be still a long time away.Thanks
Please have a look at https://jazz.net/products/rational-team-concert/whats-happening#plan for the relative order as known today.
There has been work done already, but it is a phased approach.
The above discussion is accurate, and I'm not sure I can add any more suggestions that were not already mentioned. Since this question does involve gaps, I'd like to point out some new gap related features that do change the way users deal with gaps.
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
<continue reading my next comment> (there's a limit in the # of characters per comment)
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
There are some few uses cases where you want to be able to have a repository workspace visible to the public.One of it is to allow your build system to load its data and do a build. (Keep in mind, the build does not change any data on a private workspace to avoid these issues.) There might be some more.
In general I would not recommend to work with several users against one repository workspace. All mechanisms in RTC SCM are built to support changes from different repository workspaces flowing in and out of a stream against several repository workspaces. The whole Idea is to allow to isolate your personal state of work on the server and not forcing you to see changes from others, unless you want to.
If you need the exact data of a repository workspace I would suggest to create a new repository workspace from that workspace and flow the data in. That way you can work on it in an isolated way and flow changes back to the original stream. I think you should, otherwise, not work against the same repository workspace with multiple users at all.
For example you should not even work against the same repository workspace in parallel on one machine with different Eclipse instances. If you need to work on two instances, create a stream and two workspaces that flow against it. Otherwise you get all kinds of effects, like gaps or other conflicts, if you are not careful.
RTC is built to allow sharing parallel work on stream level using flow targets, not on repository workspace level (although they are pretty much the same).
Just my 2 cents.