Today, whenever git tf checkin is executed a lock is acquired on the root of directory that is mapped in git-tf. Some users have complained that this is blocking them pretty often when files they did not touch is locked by their peers.
To better handle this I think we can do the following when git-tf checkin is executed:
1) Determine the next changeset number (CS#)
2) Do not lock the directory
3) Perform the checkin
4) If the changeset number checked in is equal to CS# determined in step 1 then the repo is in good state
5) if the changeset number is NOT equal to the CS# this means that there have been a change that was checked in before our change and our repo might not be in a good state so we need to perform further checks
- Look at the CS that have been checked in, if any of the files are in the scope of the directory mapped by git-tf in the repo then indeed our repo is not in sync with TFS. So mark the repo as in bad state (in the config) if the user tries to perform any
operation ask the user to execute "git tf fetch --force" to fix the repo first
6) Provide the user a way to fix this using git tf fetch --force OR git tf pull --force ... these commands will perform a forced get in the repo to fix the state.
I think we still need to keep the lock in deep mode because deep checkins can take a while depending on the number of commits. However, I think using the same technique used in shallow mode can also work.