Dealing with unresolvable conflicts
I have a situation where I cannot merge a stream due to unresolvable conflicts. Yes, I have tried getting the uuid of the file from the changeset, this does not fix my issue.
$ lscm conflicts
Conflicts:
Cc- (2328) /PROJ/core/hardware/app_virtual_demo.rc.gpp (Modified <-> Modified)
C-- (2328) /PROJ/core/hardware/app_virtual_demo.rc (Moved <-> Moved)
Problem running 'conflicts':
Unresolved conflicts remain.
$ lscm resolve -c PROJ/core/hardware/app_virtual_demo.rc
Problem running 'resolve':
"PROJ/core/hardware/app_virtual_demo.rc" is not in conflict.
$ lscm resolve -c PROJ/core/hardware/app_virtual_demo.rc.gpp
Conflicted items have been successfully resolved.
$ lscm conflicts
Conflicts:
Cc- (2328) /PROJ/core/hardware/app_virtual_demo.rc.gpp (Modified <-> Modified)
C-- (2328) /PROJ/core/hardware/app_virtual_demo.rc (Moved <-> Moved)
Problem running 'conflicts':
Unresolved conflicts remain.
$ lscm -u y list changes 0725
Change sets:
(0725:_g6GcQXvTEeSI854Fc8OZ_A) ----$ Joe User "Additional tuning"
Component: (5455:_U8jcsNFsEd-9Jpi2ePnVVQ) "PROJ"
Modified: 09-Dec-2014 01:53 PM
Changes:
---c- (2321:_ZSSBoL8BEeKJjshahtzobg) /PROJ/Build/Build.beta
---c- (2322:_qEIMkMcNEeO2IcWwcp6KEA) /PROJ/Build/Build.RC
--a-- (2323:_lTn7EHvwEeSMt9X4yULIow) /PROJ/core/hardware/app_hwdetect_functions.sh
--m-- (2324:_GHHY0KvIEeOPqo23p02Bvg) /PROJ/core/hardware/app_vmware_demo.hwdetect (Renamed from /PROJ/core/hardware/app_virtual_demo.hwdetect)
--m-- (2325:_5mCKUJCcEeGdzrIvLrw90g) /PROJ/core/hardware/app_vmware_demo.kernel.args (Renamed from /PROJ/core/hardware/app_virtual_demo.kernel.args)
--mc- (2326:_GHH_4KvIEeOPqo23p02Bvg) /PROJ/core/hardware/app_vmware_demo.modules (Renamed from /PROJ/core/hardware/app_virtual_demo.modules)
--m-- (2327:_v44XgK31EeO0Ovq5A7MxMA) /PROJ/core/hardware/app_vmware_demo.ovf.in (Renamed from /PROJ/core/hardware/app_virtual_demo.ovf.in)
--mc- (2328:_C5tbYIkbEeOEFsMfFKHRhA) /PROJ/core/hardware/app_vmware_demo.rc (Renamed from /PROJ/core/hardware/app_virtual_demo.rc)
--m-- (2329:_Sf-v0OkWEd-ybYnfgBR0xg) /PROJ/core/hardware/app_vmware_demo_settings.sys (Renamed from /PROJ/core/hardware/app_virtual_demo_settings.sys)
---c- (2330:_Sf1l4OkWEd-ybYnfgBR0xg) /PROJ/core/main/Makefile
---c- (2331:_SM2YcOkWEd-ybYnfgBR0xg) /PROJ/knoll/make/knoll_hwdetect.mk
---c- (2332:_B9n-ASLZEeGJu45tJbujwg) /PROJ/knoll/make/project_definitions.mk
Work items:
(1349:_I60mQGnYEeSywZIssDTkjQ) 62571 "vAPP: Virtual demo needs to be tuneable to support enablement training and CTP demos"
$ lscm resolve -c _C5tbYIkbEeOEFsMfFKHRhA
Conflicted items have been successfully resolved.
$ lscm conflicts
Conflicts:
Cc- (2328) /PROJ/core/hardware/app_virtual_demo.rc.gpp (Modified <-> Modified)
C-- (2328) /PROJ/core/hardware/app_virtual_demo.rc (Moved <-> Moved)
Problem running 'conflicts':
Unresolved conflicts remain.
2 answers
The command line is fine for simple every day operations, but for anything complicated (such as you describe here), I would strongly recommended looking at the repository workspace in the Pending Changes view (in Eclipse, Visual Studio, or the Windows Explorer). This will give you a rich graphical description of what is going on, as well as wizards to resolve any conflicts.
I would prefer to be able to resolve my issues without having to open an Eclipse GUI. There are often situations where we need to work on remotely located machines, which make using the GUI impractical at best.
Anyways, I was able to resolve the issue in a way by re-merging and letting RTC merge the offending file like before. Now, however, I proceeded to set aside a copy of the offending file. I then ran 'lscm undo' on the file to remove the merge RTC did in my sandbox.
After this, I was able to resolve the file (by UUID), which I had to do twice to get rid of both conflicts for the same file. I then restored the copy of the file that I set aside and checked that in.
I believe that RTC is unable to resolve the type of conflict I had if the merge is checked in first.
Comments
Also, I should mention that I was not able to undo the file in my original merge attempt because RTC will not let you undo a file after you check it in if it is part of a merge, hence my new merge-from-scratch approach.
Matt,
I believe the .gpp file is a temporary file that was created, correct? I am not sure if .rc and .rc.gpp files were two separate files why they were assigned the same aliases.
It is best if you could open a defect and add more details on the exact steps to reproduce.
No, I believe that the .rc file was renamed to rc.gpp. In two different streams the files were edited. The two files show the same alias. A couple other developers did the editing and moving, so I would have to gather some info from them to get a 100% the steps to reproduce.
Comments
Matt Kubilus
Jan 07 '15, 4:08 p.m.I should mention, I'm using the Linux RTC CLI version 4.0.7.
Shashikant Padur
JAZZ DEVELOPER Jan 07 '15, 11:15 p.m.The conflicts command shows two files with extension .rc and .rc.gpp both with the same alias 2328. In your listing of the changes in the change set I didn't see the rc.gpp file. Was that accepted as part of another change set.
Matt Kubilus
Jan 11 '15, 11:01 p.m.lscm conflicts -m and -p show different data from each other and what is in the merged result currently in my workspace. From what I can tell, a single file was modified and renamed in different streams. These modification changesets are far enough back that I can't simply not accept them without causing a gap.