Get Latest showing dropped objects

A SQL Server Management Studio add-in to source control your database in Subversion or Team Foundation Server.

Moderators: Chris Auckland, David Atkinson, sherr, PhilScrace

Get Latest showing dropped objects

Postby amumaugh » Thu Jun 30, 2011 6:47 pm

I have a database fully committed to source control but when I switch to the \"Get Latest\" tab, it shows me objects that have been dropped. They are obviously not supposed to be there as I have just committed all changes from the exact same db.
amumaugh
 
Posts: 13
Joined: Thu Jun 30, 2011 6:40 pm

Postby james.billings » Tue Jul 05, 2011 1:05 pm

Thanks for your post. Could you clarify exactly what's happening here? As I understand it you:

- linked a database to source control.
- committed all objects
- went to Get Latest, and saw drops listed.


Are the drops for the same objects you just committed? What sort of time was there between when you committed, and when you went to Get Latest? Are other users also linked to the same source control location, and if so, do they have their own local databases (Dedicated) or do you all work on the same database (Shared)? Does the problem clear itself if you unlink + relink the database?
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Postby amumaugh » Tue Jul 05, 2011 1:42 pm

This database has been under source control for several months. There have been many incremental changes committed over this period. I am the only developer. I recently got a new laptop and restored a version of the db to it. I wanted to make sure everything was in sync with what was on our central development server so I committed any changes that weren't already committed, switched to my local machine, linked my restored db to source control and went to get latest. There are objects showing up that have been dropped for some time now.

To answer your questions more directly:
The objects are not the same objects just committed. Since these weren't the objects just committed, I would say anywhere from 1 week to several months between when the drops were committed and when I tried to get latest. There are no other developers linked to the source control location, although I have 2 different machines that I develop on linked to the same place. Unlink and relink does not resolve the issue.

It's basically like a/some commit(s) for dropped objects did not take in source control.
amumaugh
 
Posts: 13
Joined: Thu Jun 30, 2011 6:40 pm

Postby james.billings » Tue Jul 05, 2011 1:52 pm

Thanks for your reply.

Drops on the Get Latest tab will be where you have the object in your local database, but not in the source control repo. So if this is showing up objects that have been dropped over a period of a couple of months, it sounds like the local DB still has them in.

Normally when you want to link a \"fresh\" database to source control, you can skip the restore, and instead create a new blank DB then just do a Get Latest.
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Postby amumaugh » Tue Jul 05, 2011 2:05 pm

The dropped objects are listed as Adds since the objects were actually dropped in the db but the repo thinks they're still there.

A backup is used because of the complexity of our structure and data. A close to complete data set is needed for testing so a backup is easier than a fresh db and ETL. Either way, the comparison would still create those objects that should no longer actually be in source control because they were dropped and supposedly committed.
amumaugh
 
Posts: 13
Joined: Thu Jun 30, 2011 6:40 pm

Postby james.billings » Tue Jul 05, 2011 2:09 pm

Ah, sorry - when you said it was showing as drops I thought you meant the Get Latest tab wanted to drop them from your local DB.

If they are listed as Adds, then yes, it does sound like previous commits didn't get rid of them for some reason. Seems a little odd, if there was a problem deleting the file I would have expected an error to be thrown.

One workaround, depending on the number of objects, would be to delete the files manually from your Repo (using Tortoise for example, if you're working with SVN) and refreshing.

Failing that, if you're happy your local DB is up-to-date you could remove the folder completely from your repo, recreate it, then perform an \"initial\" commit again.
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Postby amumaugh » Tue Jul 05, 2011 2:21 pm

I wasn't sure if I could just remove the .sql files and everything still be ok. When I 1st set up SQL Source Control, it seemed very particular about setting up it's own structure so I figured any manual intervention would muck things up.

I don't want to start over in the repo because then I lose all of my history.
amumaugh
 
Posts: 13
Joined: Thu Jun 30, 2011 6:40 pm

Postby james.billings » Tue Jul 05, 2011 2:36 pm

Fair enough - you should be ok to delete the relevant .sql files - I'd then suggest unlinking and relinking to ensure your temp copies are up to date.
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Postby amumaugh » Tue Jul 05, 2011 4:24 pm

I got latest on a fresh db, dropped just those objects that shouldn't have been there, then committed just those drops. Still not sure why it happened in the 1st place but that seemed to work. Thanks for your workaround anyway.
amumaugh
 
Posts: 13
Joined: Thu Jun 30, 2011 6:40 pm

Postby james.billings » Tue Jul 05, 2011 4:25 pm

Glad to hear you're up and running!
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.


Return to SQL Source Control 1

Who is online

Users browsing this forum: No registered users and 0 guests