List of Changes to Commit is Out of Date
SnapJag
Posts: 4
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.
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.
Greg L. Wright
Sr. DBA \ Consultant
snapjag.com
Sr. DBA \ Consultant
snapjag.com
Comments
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?
Redgate Software
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
"Be wary of strong drink. It can make you shoot at tax collectors…and miss" Robert Heinlein
blog: http://datacentricity.net
twitter: @datacentricity
1) unlink DB from source control
2) link DB back to source control
issue went away ... ;-)