How to temporarily safely ignore files/changes from TFS

Question

Where I work we have a long build process that includes more than a dozen modules. I work in module [A], and it often happens that code is checked into module [A] at the same time as code is checked into module [B] and [C] (this happens when a developer is working on cross module items).

The problem is that I periodically get latest on my module (necessary for other reasons relating to dev database schema concerns) and the new code can reference code in other modules ([B], [C], et..) which hasn't been built yet in our daily build. I can pull down modules [B] and [C] and build them myself, but due to the configuration involved in our build process...this could take hours.

My solution so far has been to comment out the code which contains the functionality that isn't yet available, and then try to remember not to check those comments in when I am done with my work. Is there a way to mark a file checkout (or a series of file checkouts) as temporary?

Short Version

How do I mark part of my changes so that when I go to check-in that those changes (and not the rest of my changes) are ignored / undone?

--Edit

I can't use branching because of sync issues involving our dev database and our home brewed ORM.

Answer 1

Isn't this what TFS Shelvesets are for? You can put all your changes into a shelveset to be commited later, then work on the existing code as things stand.

Shelvesets are a good way to have your changes waiting if you aren't ready to fully commit them yet.

Answer 2

The answer I found was to use a TFS feature called cloaking. I can cloak a folder containing the offending code, and then I won't mistakenly check in code changes that I am trying to ignore. It is still somewhat cumbersome in that I need to make sure to turn off cloaking once I am done, but at least I wont be erasing good code on accident.

Answer 3

Short answer: No. Sorry.

As a tip it sounds like you need to consider your branching strategy. You may be best off creating a branch for your work so that you can work in isolation and then merge back your changes into the main branch when your work is complete. Just remember to pull from main branch regularly after the build process completes so that your final merge is relatively pain free.