Why would local changes be overwritten when delivering?
![]()
Andy Jewell (242●3●63●74)
| asked Oct 29 '13, 11:59 a.m.
edited Oct 29 '13, 12:28 p.m. by Millard Ellingsworth (2.5k●1●24●31)
When I try to deliver with uncommitted changes, I get this message:
C:\Users\O386600\mberelease_preprod>lscm deliver -r local -t "MBE Release" -s "mbe release preprod o386600" -v
Of course, I obey and check everything in! But my question is -- why would uncommitted changes be overwritten in the first place? If I accept a change, that makes perfect sense. Just not sure why that is the case for a delivery. Thanks for any insight!
Andy
|
Accepted answer
![]()
That looks like it was a poor name for the option. Functionally, it's correct to confirm that you are delivering with uncommitted changes. However, the command does not overwrite your uncommitted changes. It only delivers your changes without checking in the unresolved changes first. I think a better name for the option is "--override-uncommitted" or "--ignore-uncommitted". Your unresolved changes will still be there after delivery.
Andy Jewell selected this answer as the correct answer
Comments Ahhh, so this is not saying your unchecked-in changes will be overwritten, just that they won't be delivered? Yes, I've tested it out and your changes will still be there after the delivery. It is probably a resused message from the accept case where the accept operation may overwrite any unresolved changes.
For anyone else that stumbles across this in a Google search. I filed a RTC workitem to fix this issue and to rename the option to something like "--ignore-uncommitted". You can track the progress on work item 297738. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.