SCM problem: unresolved incoming changes
Hello,
we face from time to time into a SC problem, which is not easy to reproduce. A collegue A of mine has the auto check-in option disabled. When another developer B delivers some changes, he accept those changes. The problem is that sometime this changes by B will apear at A's pending changes as UNRESOLVED changes (like before a check-in), but with a grey MINUS (remove) symbol instead of a blue PLUS (add) symbol. What happens if the user A is doing a check-in in this case? He told me, that an 'undo' operation was removing those files from the view. But what happens if he does a check-in? Will B's files be lost? The client version is 2.0.0.0. The problem apeared on both, server version 2.0.0.0 and after the upgrade on 2.0.0.2. The deliver rule 'assign work item to changes' was set mandatory on client side. Is anybody able to reproduce this problem as well? Any solutions? |
8 answers
Hello, The only reason I can think of where accepting a change set will create unresolved changes is when there are conflicts. Does user A have outgoing change sets? Affected change sets and the unresolved changes will have a little red decorator to indicate that there are conflicts to resolve. |
|
Thanks for the fast reponse. There are no outgoing changes, so no conflicts in the pending changes. This workspace has not been modified by A for a long time.
If you want I can send you a srceenshot. |
|
|
|
Something may be wrong with accepting the incoming changes. The remote workspace seems fine because the unresolved changes are showing up. It seems that the sandbox on disk is not getting the changes. Checking in these unresolved changes is not going to get the desired result.
Try reloading the workspace to get the local workspace in sync with the remote workspace. You can also check the history of the component to see if the workspace successfully accepted the changes. |
|
This seems to be a RTC-defect then.
The problem is how to reproduce it, as this problem occours for us rarely and unpredictable. |
Have you looked in the error log? If there was an exception during the
accept, it may have been logged. If there appear to be exceptions in the log whose timestamp match the time of the failure, then please open a defect and attach the error log file. Michael schinal wrote: This seems to be a RTC-defect then. |
|
Hi, next time we face this problem we will check in the log. But I don't think that there will be an error. As tmok mentioned, there is a problem on synchonising the client side file system with the server side workspace...
Besides it seems more like functional-logical problem, rather then a programmatic error. Have you looked in the error log? If there was an exception during the This seems to be a RTC-defect then. |
|
If an error was logged, it should still be there. Check the Error Log view for anything around the time this happened.
|
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.