Tag: Git

Connecting SQL Source Control to Git in Team Foundation Service

Team Foundation Service is Microsoft’s hosted TFS, and supports both Git and TFS source control.  TFS(ervice) is free for teams up to five, and all repos are private.  If you need a Team Foundation Service account, go to http://tfs.visualstudio.com and log in with your Microsoft ID.  If you’re using Git, you’ll also need to create an alternate set of credentials to connect to the repo.

In SQL Source Control, Git is now a top-level provider, but full Git support hasn’t been implemented yet (Subversion and TFS have much better support in the current version, 3.4 at the time of this post).  For the current version of SQL Source Control, you’ll still need to switch to your favorite Git tool for add/commit/push.  Upcoming features in SQL Source Control for Git include better branching support and support for migrations.  Migrations allow you to alter schema objects without dropping them first—like changing the name of a table without dropping it first—as well as seeding initial data.

1. Create project in TFS

image

 

2. Navigate to Code tab, clone the repo in your favorite Git tool using the URL provided.  TFS only supports HTTPS right now, so you need a set of alternate credentials to use Git.

image

image

 

3. In SSMS, right-click the database you want to put under source control and select “Link database to source control”.

image

 

4. Then, browse to your working folder and select whether each developer will have their own copy of the database, or everyone will work from one central database.

image

 

5. Once the database has been linked, click on the “Commit Changes” tab and choose “Save Changes”.  For a Git repo, this just saves the script files—you still need to do an add, commit and push in your favorite tool.

image

 

6. Once you’ve done an add/commit/push, you can log into TFS again and use all the functionality of diffs, history tracking, etc.  Your other team members can pull from this repo and use SQL Source Control to easily keep their instances up to date.

Should you check NuGet packages into source control?

A short time ago I posted a question on Twitter about whether people who use NuGet check the actual packages into source control.  There weren’t many answers one way or the other, but a lot of people were curious about an answer.  After some trial and error and experience, I can say this conclusively:

Do not check your NuGet packages into source control.

There are several reasons for this:

  1. Doing so violates one of the concepts of NuGet, which is to easily manage the latest versions of dependencies.
  2. Checking in packages greatly increases the size of the repository.
  3. By default, TFS ignores DLLs, but will check in manifest files.  This causes problems on build servers, since NuGet looks for the manifest, and if it finds one, won’t try and pull the package.  The dependencies you need don’t get deployed.

Here’s the right way to handle this:

  1. Right-click on your solution and select Enable NuGet Package Restore.
  2. Add your NuGet packages to your solution, if you haven’t done so already.
  3. Make sure packages.config is included in your solution, and is committed to source control.
  4. Make sure your packages folder and repositories.config are included in source control, but ignore the individual package folders.
  5. Re-read Step 4.  The key thing here is you want to ignore the folders for the individual NuGet packages.  This can be tedious with a lot of packages, so sometimes a GUI is nice.image

Now, when you go to build your solution, the packages you reference will be pulled fresh by the build server.