scm checkin fails when component is out of sync
2 answers
the workspace was potentially modified in Eclipse (e.g. changes accepted)If you are talking about the "repository workspace", which means that you have "scm" working in one sandbox, and "RTC Eclipse" working in another, with both connecting to the same repository workspace, then it is a big no no. This use case will cause "out of sync" without doubt.
If you simply use "scm" and "Eclipse" working in the same sandbox, I cannot imagine how it can cause "out of sync". And you'd better find out the pattern "out of sync" occurs.
Once a sandbox gets "out of sync", reloading the entire sandbox is usually the only option since RTC does not know which individual file is out of sync.
Comments
Thanks for the response. I think you may have hit on something. I was running Eclipse and scm on two distinct sandboxes, connected to the same repo. What information does RTC not have to support this? It knows the files changed, it knows the state of my sandbox. I could see resolution in a couple of ways, one, kind of hack would be a "checkin --force" option. A better solution would be simply allow the load workspace to merge unresolved change (of course some risk of the merge doing something weird, as can happen in SVN)
I can't run Eclipse and scm on the same sandbox because I work mostly in Linux without access to Eclipse. But using Eclipse is useful for many actions, such as deliver/accept, etc.
I guess there is the .jazzShed that may largely save the day. I could do a load --force, and then copy the files from the shed back in. Would still think an in place merge would be what is expected. Or at least a load --update option. Something not as brutal as a --force, which should be renamed to --eraseall for clarity. Actually, load --update should be the default. There should be no issue in running load twice. Being presented with 15 errors is confusing to the end user.
WHY ARE RESPONSES LIMITED TO LIKE 100 characters???!?!?! This is uber annoying. I have to do so many hacks to trick the system to allow a normal paragraph length response. This must be a forum bug, no?
There are currently quite a few enhancement requests on how RTC handles sandbox synchronization, such as this one.
https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/341373
You may open new enhancement requests for your ideas of how to improve RTC loading the sandbox.
On the forum, "comment" has the limit of 1000 characters, but there is a trick to workaround it - post the content as an "answer" (which does not have the same limit) then convert it to a "comment".
OMG, that is an awesome workaround. Much better then what I've had to do which is edit the html source and remove everything inside the <> characters. 1000 characters in HTML is actually about 500 characters (or much less) of actual readable text.
I've submitted work item Improve handling of resynchronizing a workspace component (344701) to request better handling of unresolved changes when synchronizing a de-synchronized sandbox.