A strange synchronization/checkin error
One of our users encountered this error when trying to check-in the changes to a plain text file:
Can anybody shed some light on what the error is and how it is triggered? I cannot recreate this with conflicting change sets from two different users as I can check-in the changes but only get a standard conflict error during the delivery phase. The report I got was that there is no other incoming change set to the workspace.
Unfortunately one of the SCM lead resolved the issue by rolling back the version to a stable one and then merging the new changes. This effectively wiped some interim changes in the history so I have to rely on the provided screenshots. I was hoping somebody can give me some clue on the why so I can piece together enough of what happened.
Thanks.
ciao!
Checking-in changes to new change set
Error during upload
Failed to upload File /AB/CB/BANK0001
Must claim predecessor before storing successor content
Error during upload
Failed to upload File /AB/CB/BANK0001
Must claim predecessor before storing successor content
Can anybody shed some light on what the error is and how it is triggered? I cannot recreate this with conflicting change sets from two different users as I can check-in the changes but only get a standard conflict error during the delivery phase. The report I got was that there is no other incoming change set to the workspace.
Unfortunately one of the SCM lead resolved the issue by rolling back the version to a stable one and then merging the new changes. This effectively wiped some interim changes in the history so I have to rely on the provided screenshots. I was hoping somebody can give me some clue on the why so I can piece together enough of what happened.
Thanks.
ciao!
3 answers
Can anybody shed some light on what the error is and how it is
triggered?
This error means a client tried to commit content and said that its
predecessor was content that was never committed before (as far as the
server knows).
This can happen when someone rolls back the DB to a previous backup/
snapshot. Rolling back a DB like that will leave the clients out of sync
with the server and cause these sorts of errors.
- Dmitry
So essentially it is impossible for this to happen if the user synchronized his repository workspace with the stream first? If somebody rolled back the stream version to a previous snapshot/baseline then the user will then have that locally when everything is synchronized and loaded properly. Assuming this flow (B-Baseline, U- User modification):
B1 -> U1 -> U1 -> U2 -> U2
If User3 has a latest view yesterday with some local changes and somebody rolled the stream content back to B1 today then would RTC recognize the (U1 -> U1 -> U2 -> U2 + local changes) as all pending changes if he synchronized with the stream today? Or would RTC throw that predecessor content as the user repository still recognizes the U1 and U2 changes as belonging to a change set that is no longer connected to the stream?
Thanks.
ciao!
B1 -> U1 -> U1 -> U2 -> U2
If User3 has a latest view yesterday with some local changes and somebody rolled the stream content back to B1 today then would RTC recognize the (U1 -> U1 -> U2 -> U2 + local changes) as all pending changes if he synchronized with the stream today? Or would RTC throw that predecessor content as the user repository still recognizes the U1 and U2 changes as belonging to a change set that is no longer connected to the stream?
Thanks.
ciao!
So essentially it is impossible for this to happen if the user
synchronized his repository workspace with the stream first?
No, this has nothing to do with SCM operations, all of those should work
without causing this problem.
What I meant was that someone with access to the DB itself used a DB
command to rollback to some previous point in time.
- Dmitry