scm checkin fails when component is out of sync
When we have unresolved changes in our sandbox and attempt to execute a checkin, we can get an out of sync error because the workspace was potentially modified in Eclipse (e.g. changes accepted). The suggested resolution is to load --force, but that will remove all unresolved changes. There appears to be no way to continue forward, baring just copying all changed files away, doing the load, and then hand merging them back in.
Am I missing a key step?
scm load should have an option to not blindly overwrite all files. The --force option is required when there are no changes
scm load ....
scm load ...
[fail, already loaded]
it should just detect, already loaded, load is successful. Like an svn update.
|
2 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Feb 04 '15, 6:22 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Feb 05 '15, 7:45 p.m.
The general rule I recommend is "an operation that modifies the configuration of a workspace that is loaded into a sandbox should only be performed on a client that is connected to that sandbox". If you want to modify a workspace without access to the currently loaded sandbox with unresolved changes, you should "unload" the workspace from the currently loaded sandbox before performing those modifications. In particular, this means if you have any unresolved changes in the currently loaded sandbox, you should first either checkin those unresolved changes to save them, or undo those changes to throw them away.
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. |
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.
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. |
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.