1

We are using ClearCase using a single Dev stream for our team, without 'locking' (Unreserved check outs).

ClearCase client version: 7.1.1 ClearCase server version: 7.0.1.2

We have performed the same test, without using the "Graphic merge". This option worked as expected! Maybe this can shed some light on past defects on ClearCase or workarounds.

This means that 2 or more people can make edits to the same file at once, without having to wait for for the file to be checked in.

We have seen a few cases of weird behaviour and experimented a bit today to find the following scenario that takes place:

  1. File.txt is checked out by 2 team members.
  2. Each members makes a change in the file (in other regions of the file).
  3. First developer checks in the code to ClearCase, no problems here.
  4. Second developer checks in, gets a merge popup notification.

When selecting "graphic merge", ClearCase in this case informs that all merges were done automatically and no additional input is needed from the developer.

Looking a little further, the first check in was removed (deleted), keeping only the later check in changes.

Why is this happening? This is causing our team to lose code on several occasions already. Are we doing something unsafe/wrong ?

Edit: Illustrating the problem with images of the issue:

The file Manager.cs is at version 27. Two developers are checking it out.

One made a change, checked in. The other checks in, gets the merge notification.

This is what i see in the graphical merge:

Note that on the left is version 27, in the middle version 28 (the latest checked in version), and on the right is the result which is dropping version 28's code change !

Why is this happening automatically??

Merge

Image can also be seen here: Image

Zoe
  • 27,060
  • 21
  • 118
  • 148
lysergic-acid
  • 19,570
  • 21
  • 109
  • 218
  • No the right isn't dropping the code change. The right is the file currently checked out by dev2, with dev2 changes. The result of the merge is on the top part of that screenshot, and does drop the line added by dev2. What is strange is that, in a 3-way merge, ClearCase should choose to keep base/dev2 version (no new line added) instead of source version (1 new line added). Is this through the classic merge tool with a full ClearCase client, or with an external diff/merge tool?, or through some web-based interface with CCRC? – VonC Nov 24 '11 at 10:40
  • http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.tutorial.doc/a_how_cc_merges.htm: "For any line that has changed between the base contributor and another contributor, Rational ClearCase performs a trivial merge by accepting the change in the contributor". So it should keep dev1 changes (version 28) – VonC Nov 24 '11 at 10:42
  • Standard install, no custom merge tool. Using clearcase explorer to checkin and handle merges... Could this be configurable as a policy? – lysergic-acid Nov 24 '11 at 11:32
  • it can be defined a a policy for a given type: https://www-304.ibm.com/support/docview.wss?uid=swg21240740 But this shouldn't be the case for txt file. By the way, what version of ClearCase are you using? – VonC Nov 24 '11 at 12:05
  • I need to check my client is 7.1.1 – lysergic-acid Nov 24 '11 at 12:17
  • Note to self: http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/index.jsp?topic=/com.ibm.rational.clearcase.hlp.doc/cc_main/how_merge_file_dir.htm is another link explaining how merge works. – VonC Nov 24 '11 at 12:17
  • Just to be sure: did dev2 introduce any space/tab in those two empty lines? – VonC Nov 24 '11 at 12:18
  • The picture shows what the change was.. None of the two changes were only blank lines... – lysergic-acid Nov 24 '11 at 12:30
  • I have updated my answer to fit your new elements. – VonC Nov 27 '11 at 16:27
  • Not sure i understood completely - are you suggesting we should attempt to run the same from command line? (that would be the identical to a non graphical-merge?) Also, i currently have no other option regarding the Client... (the server won't be updated in a while, and the older clients i suspect do not support Win7) – lysergic-acid Nov 27 '11 at 18:21
  • The "graphic merge" seems to not working with this combination of client-server version. So either you don't select it (which you report working), or you try it from the command-line. But regarding the clients, you are right: Windows Seven is only supported from CC7.1.x – VonC Nov 27 '11 at 19:13

1 Answers1

1

Note: if you are using ClearCase without 'locking', that means you are doing unreserved checkouts (and not reserved checkout).

If you select "graphic merge", you should see a Windows helping you to reconcile the merge, even if there is no conflict.

Such a merge should not delete any previous checkins: it might cancel the previous modifications, only if all the new changes are selected, but if you have the graphical merge window open, you can control how the merge is applied.

For your past problematic merges, you can easily from the version tree re-apply the merge from the previous version of dev1 to the LATEST version, in order to reapply those canceled changes.

Since my initial answer 4 days ago, 2 new information came about:

  • ClearCase client version: 7.1.1 ClearCase server version: 7.0.1.2.
    That is never good to have a client with a version more recent than the server.

  • We have performed the same test, without using the "Graphic merge". This option worked as expected!
    That would be consistent with some discrepancies already seen between the GUI for merging and the pure command line (as in this other scenario).
    When the GUI fails, always try to fall back on the pure CLI (Command Line Interface).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I meant unreserved, it was a mistake. The automated ClearCase merge window specifies that it was able to automatically merge both versions. However in this case it removes the changes made by a previous check in automatically. Merging larger files make it practically impossible to detect these unless going over all merge points whether automated or manual (maybe this should be the practice?) This is totally counterintuitive for us, and causes us many issues. – lysergic-acid Nov 23 '11 at 12:52
  • @liortal: but looking at the version tree of that merge file, do you confirm you didn't *lost* dev1 changes (in that dev1 checkin is still there)? The issue is then the new checkin done during that trivial merge which seems to cancel dev1 changes, leaving only dev2 changes, right? – VonC Nov 23 '11 at 13:53
  • Sorry if i didn't express myself with the exact correct terminology. In the version tree i am able to see two nodes (versions): one which is the earlier, which contains dev1 changes. The second one contains only dev2 changes. You may call it cancel or delete dev1 changes, whatever the term is, in the newer version, dev1 changes are gone from the newest version of the file. Finding this later on after many checkins were made, makes it impossible to reapply the changes to the newest version. Why is ClearCase acting like this? is this standard behaviour? – lysergic-acid Nov 23 '11 at 14:05
  • @liortal: no it is not. It should only add dev2 changes, not remove dev1 ones. Is dev2 using a snapshot view? – VonC Nov 23 '11 at 14:10
  • All our team are using Snapshot views. – lysergic-acid Nov 23 '11 at 14:16
  • @liortal: what should happen in this instance is a three way merge with: base equals to the version just before dev1 version, source equals to dev1 version (already checked in by dev1) and dev2 current work: when dev2 checks in, this is the three way merge he/she should see. Selecting the "graphical merge" option should trigger the opening of that three-way merge window. Can you test that? (and make sure you are in that exact situation when dev2 makes his/her checkin?) – VonC Nov 23 '11 at 14:57
  • we have already tested that today. Indeed we see a 3-way merge graphical merge option. Selecting it mentions in the test scenario we were doing today "2 merges done automatically, 0 needed to be done". When going over the changes that were made, dev1 changes were removed... If i confirm the check in , basically what i will get is only dev2 changes (coming from base), meaning i lose ALL dev1 work. I can show an exact screenshot of this tomorrow if my explanation is still not very clear. – lysergic-acid Nov 23 '11 at 15:29
  • 1
    But the base shouldn't be dev2, it should be the version before dev1's version. A screenshot will be interesting indeed. – VonC Nov 23 '11 at 15:43
  • The base is indeed the version that the 2 developers were based on (version prior to dev1). I will take a screenshot tomorrow in the office. – lysergic-acid Nov 23 '11 at 16:46
  • Edited the question with screenshot and details of the exact scenario. Notice that i didn't run "Update" before checking in my version, is this related? should this be a must ? – lysergic-acid Nov 24 '11 at 08:31
  • @liortal when you say `i didn't run "Update" before checking in my version` which version is `your` version.. the dev1 or dev2 ? Also, you can rest assured this is NOT standard clearcase behavior and till now whatever you have written is pretty standard stuff. This deletion should NOT happen. Let us investigate more – Pulak Agrawal Nov 25 '11 at 04:01
  • I meant that the last developer that checked in, didnt run Update before checking in his version, even though version "dev1" already exists on the server now. – lysergic-acid Nov 25 '11 at 08:31
  • @liortal: did you make the test of doing that merge *after* running an update *first*? – VonC Nov 25 '11 at 08:33
  • No but that scenario will probably work. However we can't enforce all devs running update before every checkin... – lysergic-acid Nov 25 '11 at 09:03
  • @liortal: actually, an update shouldn't be mandatory in your case. The merge is detected anyway for that particular file. – VonC Nov 25 '11 at 09:52
  • I wonder what can be our next course of action? Escalate to IBM? – lysergic-acid Nov 25 '11 at 11:00
  • @liortal: if you confirm there is no "copymerge" policy in place, or no trigger susceptible to influence the merge, then an escalation might be in order. I just made a similar test myself, and confirm dev1 changes shouldn't be erased by dev2 version. – VonC Nov 25 '11 at 11:40
  • Edited the question with version information of CC, can this be an issue? – lysergic-acid Nov 27 '11 at 08:24
  • Edited with more information (issue occurs only in graphic merge). – lysergic-acid Nov 27 '11 at 13:17