It's all about the answers!

Ask a question

What causes the message "The following resources had uncommitted changes and were overwritten" to be displayed?


Lauren Hayward Schaefer (3.3k11727) | asked Jun 16 '15, 8:03 a.m.
JAZZ DEVELOPER
I'm running a script that resumes changesets in a repository workspace one by one by making calls using the CLI.  Sometimes, the script is unable to resume changes due to conflicts.  In this case, I load the repository workspace in Eclipse, resolve the conflict manually by selecting Resolve with Proposed (so the merges are now listed in Outgoing changes), and restart the script.  The script begins by logging in to the repo and loading the repository workspace.  Sometimes the CLI displays:
The following resources had uncommitted changes and were overwritten:
  A copy of each file is available in "C:\mypath\.jazzShed\dateddirectory".
     file1
     file2

I'm trying to understand why this would be displayed.  My understanding is that the shed is used to backup files.  Why would these files be uncommitted and need to be backed up?  This message is not displayed every time I hit a conflict that needs to be manually resolved.

Comments
Lauren Hayward Schaefer commented Jun 16 '15, 8:39 a.m.
JAZZ DEVELOPER

If you'd like more context of how/when I'm getting this error, see https://github.com/WtfJoke/rtc2git/issues/32

One answer



permanent link
Shashikant Padur (4.2k27) | answered Jun 16 '15, 11:11 p.m.
JAZZ DEVELOPER
Looks like there were some unresolved changes in your sandbox. Are the files file1 and file2 the ones you resolved the conflicts manually? Or were the files changed outside of eclipse? If the files were changed outside of eclipse then you need to run a refresh from the pending changes view for the unresolved changes to show up.

Comments
Lauren Hayward Schaefer commented Jun 17 '15, 7:01 a.m.
JAZZ DEVELOPER

I'm fairly certain file1 and file2 are not the files I resolved conflicts on manually.  I will double check the next time it happens. 

Here is what is interesting about this:  When I resolve the conflict in Eclipse, the change should be in my repository workspace and my local Eclipse workspace.  The script (which uses the CLI) uses the same repository workspace but a different local workspace.  So when the repository workspace is loaded, nothing I changed in my repository workspace in Eclipse will already be in the different local workspace--loading the repository workspace will pull it in.  So how am I getting uncommitted changes?

The message is appearing in the CLI not Eclipse.

Can you explain what the sandbox is?  I'm not sure how it relates to my repository workspace.


Shashikant Padur commented Jun 17 '15, 7:37 a.m. | edited Jun 17 '15, 7:38 a.m.
JAZZ DEVELOPER

The location where the repository workspace was loaded is referred to as a sandbox. The local Eclipse workspace could potentially be different from the sandbox location if you first create a Eclipse workspace and then import projects from another location. I believe in your case the local Eclipse workspace is the same as the sandbox location.


After resolving the conflicts, does the script load into the same old location or a new location. If it is a new location then there should not be any uncommitted changes.
I would suggest you run 'scm status' cli command after you encounter a conflict and check if there are any uncommitted changes.

By the way, if you always resolve with proposed you could also use the cli to resolve the conflicts or add it to your script.


Lauren Hayward Schaefer commented Jun 17 '15, 7:42 a.m.
JAZZ DEVELOPER

Thanks for the clarification about what a sandbox is.  In my case, the sandbox is different from the local Eclipse workspace. 

After resolving the conflicts in Eclipse, the script loads into the same old sandbox.  I'll try running scm status.

I tried to figure out how Resolve with Proposed in the CLI, but I was unsuccessful.  It looked like I had to specify the changeset of the proposed, and I had trouble figuring out how to get the correct changeset.  Is there an easy way to resolve with proposed in the CLI?  That would really save me a lot of time.


Lauren Hayward Schaefer commented Jun 17 '15, 8:44 a.m.
JAZZ DEVELOPER

I just hit a merge conflict and ran "lscm status."  I got a CLIClientException.  In the exception, I see "SyncViewDTOUtil.java."  After resolving the conflict, I got the same error.



From talking with Michael Valenta, the SyncViewDTOUtil errors were fixed in https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=315286, but unfortunately I don't have a server new enough to have the fix.


1
Shashikant Padur commented Jun 17 '15, 11:24 p.m.
JAZZ DEVELOPER

To respond to you earlier question about how to resolve conflicts with proposed using the cli...

From the sandbox location, run scm resolve conflict --proposed <uuid_or_path_of_the_conflicted_file>. You can also run from any directory but then you have to provide the option -d <sandbox_location> to the command.
You can get the UUID by running 'scm -u y show conflicts'. 'scm -u y show status' also displays the conflicts.

Note: The equivalent commands in older versions of RTC is 'scm resolve', 'scm conflicts' and 'scm status'.


Lauren Hayward Schaefer commented Jun 19 '15, 7:09 a.m.
JAZZ DEVELOPER

Thank you! That is incredibly helpful!  I got it to work when I manually typed it in.  Now I need to figure out how to work it into my script.

showing 5 of 6 show 1 more comments

Your answer


Register or to post 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.