A user in my group, new to RTC, had a Stream <-> repository Workspace <-> Eclipse workspace setup, and had made local changes in the Eclipse WS to a file F, but had not "checked-in" these changes.

Then they "accepted" some changes for that same file F from the Stream, expecting it to "merge" those changes with what was in the Eclipse Workspace; instead, to their surprise, it just overwrote the local changes, losing that work (they recovered using Eclipse "history"...).

Is this expected behavior? Why was a "merge" not done?

-Marshall Schor

There is a user prompt that asks if you want to check-in unresolved before accepting the changes. The dialog mentions that changes might be overwritten if you don't check-in.

Did your user not get the prompt?

First, I do agree that the warning message should be much clearer in
this scenario. I've submitted work item 177641 requesting this be
fixed. In particular, the warning message should be very clear "checkin
and accept" will merge your local changes with the incoming changes,
while "accept" will overwrite your local changes with the incoming changes.

But note that the developer needs to understand that she should not
believe she has to "wait until she was ready" to checkin her changes. In
RTC, a checkin is a "private" operation, in that nobody else on the team
is aware of a checkin until you have "delivered" those checked in
changes to the team stream. So the developer should always select the
"checkin and accept" option, unless she wants to lose her local changes.
In the work item, I suggest we just get rid of the "checkin" option,
since a user can always clear their local changes with an "undo" operation.

Cheers,
Geoff

On 9/16/2011 7:38 PM, marshallschor wrote:

tmokwrote:

A user in my group, new to RTC, had
a Stream<-> repository Workspace<-> Eclipse workspace
setup, and had made local changes in the Eclipse WS to a file F, but
had not "checked-in" these changes.

Then they "accepted" some changes for that same file F
from the Stream, expecting it to "merge" those changes with
what was in the Eclipse Workspace; instead, to their surprise, it just
overwrote the local changes, losing that work (they recovered using
Eclipse "history"...).

Is this expected behavior? Why was a "merge" not done?

-Marshall SchorThere is a user prompt that asks if you want to
check-in unresolved before accepting the changes. The dialog mentions
that changes might be overwritten if you don't check-in.

Did your user not get the prompt?

She mentioned she saw a prompt to "check-in", but she wasn't
"ready" to check-in. She didn't mention the part about it
saying that her changes might be overwritten. This may be because
it was so unbelievable to her, coming from years of experience
working with various source control systems, where they typically
offer to "merge" changes, in situations like this.

It sounds, though, that RTC is designed to overwrite your local
changes in this case, is that right? I'm curious why it doesn't
offer to merge them?

-Marshall Schor

Merging occurs when there is a conflict detected. A potential conflict arises from an incoming change set and an outgoing change set modifying the same content. For both incoming and outgoing change sets to exist in the repository workspace, the conflict has to be resolved to keep the history sane. It doesn't consider the local changes because those changes could never be checked in. The decision dialog is supposed to give the option to check-in the changes in case a conflict occurs.

I would recommend always checking in unresolved changes before accepting or delivering change sets. Check-in frequently and don't be afraid to use more than one change set.

I would recommend using CVS or SVN.  This is majorly broken.  Perhaps instead of a dialog box, it should be a Preference.  I'm a very unhappy user!