List of Changes to Commit is Out of Date

SnapJag

I am getting an error message "The list of changes to commit is out of date, so the commit was refused by the server." The fail happens on the Sending Files to Source Control.

SVN 1.8 (TortoiseSVN)
RedGate Source Control 3.4.8, 3.4.10, 3.5.1

How to reproduce
1) Create a new repository folder
2) Commit all items
3) Open the SVN Repo-browser
4) Copy to ... new branch location
5) Backup database from Shared DB location, which has more branch adjustments
6) Restore database to local "dedicated" environment
7) Link new restored database to this branch (Dedicated)
8) Try to commit, failure

The reason for step 5-6 is because there is another database that my developers are using to develop against a branch; we want to have an SVN branch that matches the new database schema/data set branch. If people need more information about steps and "how" in this scenario, I'll answer; however, I won't answer questions about why (unless it leads to a solution), or I haven't clarified, but I should've been able to describe why enough to provide context.

Any help to get this working, that would be great. Thanks.

James B

OK, I managed to reproduce this in the end. The important part seemed to be in step 5- the further adjustments only triggered the problem when they were a change to an object that had been previously committed.

Once I got the error I could resolve it by going to the Working Base on the newly linked DB (right click the URL on the SQL Source Control setup tab) and pick "Open Working Base"), then right clicking the 'Tables' folder (this will probably work if you just do the parent folder with the random name) then did an SVN Update.
Once I did that, I refreshed the commit tab, tried again, and it went though.

My guess is that the combination of the restored DB along with the "copy" in SVN somehow gets things out of kilter although I'm not sure exactly how yet... any SVN experts?

datacentricity

FWIW, I have been encountering a lot of this error recently. I have a suspecian (but haven't proved it) that this may be caused when I use Visual Studio's TFS Explorer to move large numbers of sql scripts between folders (actually tSQLt unit test which we store in a separate folder structure with the main source folder).

Anyway, after reading this post, I identified the working base location then in TFS Explorer used the Workspace drop down to switch the to working base location. When I did a get latest, I noted a shed load of changes so obviously the weoking base hadn't been updated properly by SSC.

Then when I tried to commit again, I got a write lock failure but after closing TFS Explorer and restarting SSMS it worked OK.

So for the guys at RedGate this seems to be a bug with how SSC interacts with TFS (at least in my case).

Specifically, when I use SSC to commit new changes including tSQLt tests, the test procedures end up in the $/Source/Stored Procedures/ folder which with over 1000 tests just gets in the way of the production sprocs. So I then use TFS explorer to move those to a different folder $/Source/Tests/Unit Tests/ and commit my changes. I think the problem occurs because although the folder path for some sprocs has changed, there are no material changes to the DB so get latest produces no changes (as you would expect). However the next time I try and commit I'm seeing the "the list of changes to commit was out of date" error

nanonerd

I tried:

1) unlink DB from source control

2) link DB back to source control

issue went away ... ;-)