Yesterday morning I took the time to work on a personal project and I wrote some great code. I wrote a class whose purpose was to enumerate the search engines that are installed in Internet Explorer so that I could implement them into a Word Ribbon, allowing you to do searches straight from Word. I got the bulk of the work done, the class was finished, it just wasn't hooked up to the project to produce output yet. I committed my changes because the changes didn't break the build, and I was on my way out to go to the renaissance festival.
Now, I try frantically to find the class and it isn't on my work laptop. The work I've done wasn't in source control because I didn't select all files when committing, and tortoise defaults to not send new files (Is that a setting? I need to check...) The result, a very sad day. I was hoping to get started on finishing the hookup and working to complete the launcher ribbon project. Now, I have to wait until I get home and can check my home laptop. I believe that is where the uncommitted class resides.
Lesson learned. I need to use greater care when committing, and as such I've created these guidelines for myself:
- When committing, first think through what you've done since last commit, and the purpose of the new commit.
- Actively peruse the updated file list and make sure to include all pertinent files.
- Never drunk-dial. Believe me, this applies to committing too.
So, by not being cautious, I can effectively say I've broken my build. Thankfully, I only broke a build on a project where I'm the only worker. However, I actively am tasting the effects of a broken build first hand.