How to handle SQL Server CE in source control?

Question

I'm curious for how we should handle SQL Server Compact in our Git source control. Everytime a developer changes data there is a binary merge conflict. Is there a way to keep development of this database in sync? If two developers pull down the source and modify the schema then one of them will lose their changes since all you can really do is accept the server version of the sdf file or the local version. What is recommended for this scenario? The benefit of having SQL Server CE in the solution is that people can pull down a fresh copy of the project, press F5, and they're off to the races. Is there some middle ground here?

I'm not so much worried about keeping data in sync, but modifications to the schema of the database. Conflicts result in a "mine" or "yours" scenario unlike code files in which you can use a compare tool to merge the two versions together.

Answer 1

Instead of creating your schema in the SDF, you could write SQL statements that create and populate the database and check those in. SQL is text, and can be merged and compared using existing tools. You would need a pre-build command to run the SQL and recreate your database.

Answer 2

I would normally approach this the same way that I would with using full blown sql server. Each developer should have a copy of their own database which is not put into source control.

As a best practice you should probably be maintaining a collection of sql scripts that migrate you from one version to the next, these are more important than having a sqlce database in source control as you can see what has changed between commits and merge changes where necessary. It also allows you to migrate data between versions.

What I usually do is have a health check component that is run at start up. The first thing it does is check to see if there is a ce database. If there is no database it will create it and run all the scripts to bring the schema up to the current version. If there is a database it uses a mechanism to determine the current version of the database (maybe a version table or the assembly version) and then run the scripts it needs to get it up to the latest version.

Answer 3

a similar problem are different eg paths for different development environments, which I usually solve like this:

I append the hostname to the key as in :

<add key="ImportPath_MyCoolUbuDev" value="d:\import" />
<add key="ImportPath_alexf" value="m:\dev\p1\import" />

maybe this will give you an idea.

i don't know, if it is feasible for everyone to keep their own copy local (named differently) and only overwrite it, when they want to upgrade themselves.

Answer 4

I ran into this same issue. Well, replace git with svn and CE with standard edition...

Our setup is such that every developer has his own copy of the necessary databases, with centralized dev, QA and prod versions. Each server (note: every server) is stored in the repository individually.

I'm using this code to script the objects, then batch files to commit to the repo. While the article discusses a solution for SVN, you should be able to very easily replace it with the corresponding git calls.

Have this run nightly on every machine with an instance of the database, and Bob's your uncle. Cheers!