I'm using git-tf to push to a TFS project. Sometimes, when I try to check one or more commits into TFS, I get a message like this:
Connecting to TFS...
Checking in to $/MyProject: 0%
git-tf: Could not lock $/MyProject
What does this mean? What's keeping me from locking? And how can I fix this?
Why it happens
With standard TFS usage, you're only checking in one commit at a time. But with Git, you could have a series of commits that you push all at once.
Because of that, git-tf strives to keep your set of commits atomic. If someone checks in while you're checking in, the history can get mixed up; it won't be merged properly.
To prevent this, git-tf temporarily locks the entire source tree while it checks in. It can't do this, though, if somebody else has parts of the source tree locked already.
How not to fix it
You'll see the --no-lock argument recommended in some places:
git tf checkin --no-lock
This is not a good solution. It ignores the potential scrambled-history problem instead of solving it.
How to fix it
- Based on the version of TFS you're using, download and install the appropriate version of TFS Sidekicks.
- Run TFS Sidekicks.
- Navigate to Tools > Status Sidekick.
- Clear the User name field.
- Set a date range sufficiently wide to encompass the whole history of your project. You can filter the Project name field if you like.
- Click Search. You'll get a list of all checked-out files in the project.
- Click on the Lock type column header to sort by that column. Most files will probably have "None" in that column. You're looking for any files that have "Locked" instead. This is most common with binary files, because they can't be merged. By default, TFS will exclusively lock them when they're checked out.
- Once you find out which files are locked, go talk to the person who has them locked and negotiate getting them unlocked. If the person no longer works there, you may want to have a TFS admin just remove the locks.
- Once all the locks are removed, hit Search again in TFS Sidekicks and you should see that all files have a lock type of "None". Now try your git tf checkin again, and it should work correctly this time.