Problem merging and resolving conflicts after applying patch

On Thu, 22 May 2008 21:47:54 +0000, davely wrote:

I am trying accepting incoming changes from team members but it tells me
that I cannot accept the change and can only apply a patch.

So I applied the patch, and manually merged the files but they still
appear in the incoming folder in work items. I know I have applied these
changes already with the patch, but they are still there as if I didn't
accept the change.

This happens because you are trying to accept an active changeset from
another contributor. The way collaboration should normally work is that
each contributor works on their own changes in their own active
changeset, and once they are ready for everyone to use their changes they
deliver the changeset to a stream.

Alternatively, you can ask them to close the changeset so that you can
accept it. Otherwise, accepting it as patch will merely create another
changeset with equivalent changes, but will not consider the incoming
changeset as accepted.

How do I get rid of them? Also, when I apply the patch, it puts the
files in an outgoing folder, (because I had made change to reflect the
incoming files), but I don't want to check these files in. What should I
do?

I believe they are already checked in to your own active changeset. If
you don't want the changes you can discard that changeset.

Now, my project has potential conflicts with almost every single file in
the project. How can I revert everything? I am ready to loose my changes
so that I am capable of accepting incoming work items without having to
apply this messy patch.

This happens because your outgoing changeset and the incoming changeset
modify the same files. See above about how to avoid this.

I also tried suspend my outgoing changes and accept all incoming files,
but again it asks me to apply the patch.

anyone knows how to fix this ?

If you don't want to apply as patch, you should either wait for the other
contributor to deliver the changeset to a stream and then accept it from
there, or you can ask them to close the changeset.

- Dmitry

I am in the process of syncing changes between two streams. To do this, I tried to accept a couple changesets from a work item. These changes had been previously delivered to a different stream.

After doing the accept, the changesets are marked as outgoing for my second stream, and I want to deliver them. However, the deliver fails with an error message about gaps in the history. Unfortunately I can't seem to find the changesets that will fill in those gaps.

Even worse is that I cannot discard or suspend them either. Seems like my only option would be to stop using this repository workspace. Is this a known problem, or just something I screwed up? In the future, I probably won't accept any changesets from work items, and will use patches instead.

Any ideas?

thanks,
Charlie

There is a workitem requesting that the system provide you help in these
situations (defect 24822), in particular, to suggest change sets that
would "fill the gap". Please feel free to indicate your support for
this enhancement by adding a comment to the work item.

WRT the issue of not being able to discard/suspend them from your
workspace, you can do something about that. This error says that in
your workspace, you created new change sets that modified files that
were also modified in those change sets you accepted from that work
item. So to fix this situation:
- suspend all the work items that you created since you accepted the
change sets from that work item
- discard the change sets from the work item (that should now succeed).
- resume the change sets that you suspended. The resume will complain
about the change sets that depend on the ones you discarded, but you
will be given the option of creating a "patch" for those change sets you
want to resume. Create patches for the change sets you can't resume,
check them in, and you should be able to deliver the results.

Cheers,
Geoff

csurface wrote:

I am in the process of syncing changes between two streams. To do
this, I tried to accept a couple changesets from a work item. These
changes had been previously delivered to a different stream.

After doing the accept, the changesets are marked as outgoing for my
second stream, and I want to deliver them. However, the deliver
fails with an error message about gaps in the history. Unfortunately
I can't seem to find the changesets that will fill in those gaps.

Even worse is that I cannot discard or suspend them either. Seems
like my only option would be to stop using this repository workspace.
Is this a known problem, or just something I screwed up? In the
future, I probably won't accept any changesets from work items, and
will use patches instead.

Any ideas?

thanks,
Charlie

Geoff,

Thanks for the tips. When I looked at the changesets again, I realized that the file I was trying to undo had changes in three outgoing changesets - two from the work item accept and the other from my active changeset. By splitting that change into its own changeset, I was able to discard everything together.


Charlie

Since this question touches on gaps, I'll add the following information related to gaps (note:It is also encouraged to also read Geoffrey's and Dmitry's answer).

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

Both features are explained in detail in the "Improved Gap Handling for SCM" article: https://jazz.net/library/article/1372

For reference, the Help for merging changes that contain gaps is here http://www-01.ibm.com/support/knowledgecenter/SSYMRC_5.0.0/com.ibm.team.scm.doc/topics/c_merging_changes_gaps.html?lang=en