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?
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,
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.
Is anybody able to reproduce this problem as well? Any solutions?
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.
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.
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.
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:
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.
The problem is how to reproduce it, as this problem occours for us
rarely and unpredictable.
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.
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
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.
The problem is how to reproduce it, as this problem occours for us
rarely and unpredictable.