February 2009 Entries
One of the goals of data migration is to preserve the integrity of existing data while altering it to be represented in another form. Enabling and disabling triggers can be very handy when migrating data – particularly if you encounter triggers that alter or create rows in other tables. Fortunately, it is extremely easy to programmatically enable/disable triggers in SQL Server 2005:
ALTER TABLE [dbo].[YOUR_TABLE] DISABLE TRIGGER [YOUR_TRIGGER]
ALTER TABLE [dbo].[YOUR_TABLE] ENABLE TRIGGER [YOUR_TRIGGER]
During the subway leg of my commute into the great city of Toronto, I noticed some marketing that made me laugh out loud – literally, not in a LOL instant messenger sort of way. Normally, this may not have been a big deal or even noticeable, but when you’re riding the rocket in rush hour traffic with three or four people rubbing up against you, its hard not to make eye contact with the awkward stares. You may not find the following all that amusing, but when it comes to long commutes using public transit, every laugh counts.
I think the statement in the big red banner make the TTC Employment Opportunities advertised above it a little less appealing.
There is one other thing keeping me amused for the duration of my commutes. I have steadily been using Git distributed version control for a few months. In fact, looking at my check-in log, I can see I have been using it since November 13. Let me tell you, distributed version control is doing wonders for me – especially because I am currently commuting like crazy.
Thankfully, Git keeps on working while I’m on the subway, taking the bus and waiting for pizza after missing the GO train due to bus delays. Committing new functionality and corresponding unit tests to my cloned Git repository while disconnected is the only thing keeping me sane.
In light of my last post where I mentioned how pleased I am with distributed version control, I thought I should share a few tips that have made my life using Git a bit easier. This post will be the first of several posts on configuring Git for daily use by a .NET developer running Windows.
One of the first things to do after creating a new Git repository is to exclude certain files from ever entering the repository. Git has several built-in methods for excluding files. I use a single .gitignore file at the root of my source code directory. It’s simple, but it works. Surely, you, Reader, will eventually need to add some project specific lines to the following basic template, but this has been working for me:
*resharper.user
# Visual Studio
[Dd]ebug/
[Rr]elease/
*.sln.cache
*.suo
*.csproj.user
# Resharper
*[Rr]e[Ss]harper.user
_ReSharper.*/
The *resharper.user files store user specific settings for a solution, so they should not be checked into the repository. Similarly, the other lines prevent build output, VS user specific solution configuration and ReSharper temporary data from ever being considered for check-ins. This is especially useful because excluded files are not listed when checking for modifications.
April 6th, 2010: added a few extra lines to ignore file.
April 16th, 2010: Resharper 5.0 uses different casing for the resharper user file.