Expanding Upon Working With Teams

Nov 4, 2012 at 10:36 PM

Congratulations on the 2.0 release!  

I have a question/concern about the working with teams workflow and am hoping that someone can shed some light onto something I'm missing or suggest a different process.

We're currently a mixed team of VS + XCode developers.  We're all working within the same directory in the repository.  To facilitate collaboration between the XCode developers we've setup a github account and pushed the initial git-tf clone to the remote repository.  We then follow the "Working with Teams" workflow.

The challenge with such an approach is that we have to rely on the single developer that initially git-tf cloned the repository to keep the shared git repository up-to-date with the TFS repository.  This introduces a bottleneck into the process.  What if that developer is sick or otherwise unable to merge?

What I understand as the problem with two developers using git-tf to directly check-in and out of TFS in the same directory is that their git commit histories would be different, making automatic conflict resolution impossible.  I thought the following workflow would be able to get around this problem:

Dev-1: git-tf clone
Dev-1: git push
Dev-2: git pull
Dev-2: (do work) git commit
Dev-2: git-tf configure <Server URL> <Collection>
Dev-2: git-tf pull
Dev-2: git push
Dev-2: git-tf checkin

Since Dev-1 and Dev-2's repositories have the same history, I don't think the merge problem should exist.  When I tested this out, it started breaking down at:

Dev-2: git-tf pull
	git-tf: this is a newly configured repository. There is nothing to fetch from tfs.

Dev-2: git-tf checkin
	git-tf: cannot perform the initial check in against a non-empty folder. Destination <destination folder> needs to be empty, please configure your repository against another tfs folder�


Should this work?  Is there another way to not have the merge of the TFS with a git repository be dependent on a single developer resource?  Maybe the actual git-tf configuration files could themselves be committed to the repository and shared across the team?

Nov 7, 2012 at 1:46 PM

Unfortunately, this will not work. Git-tf does not support "pulling" in a newly configured repo and blocks this scenario. How about this:

Dev1 : git-tf clone
Dev1 : git tf checkin

Dev2 : git-tf clone
Dev2 : git tf checkin

i.e each developer have their own tf cloned repository and work separately.

Another approach can be having a common repository that everyone can access as the git tf repository

Common: git tf clone
Dev 1: git pull
Dev 1: git push
Common: git tf checkin
Dev 2: git pull
Dev 2: git push
Common: git tf checkin

The advantage of this would be that Dev1 and Dev 2 can collaborate and push to each others repositories as well.

Let us know if this does not solve the issue you are having.

Nov 11, 2012 at 2:43 PM

Hey, thanks for the reply.

The second workflow does seem like it would work and address the bottleneck in the process that was the reason for this question.  It's not my favorite solution, but that's only because I have pretty high expectations ;)

When we started with git-tf we tried the first suggestion, where each developer did a git-tf clone and tried to use git-tf in the hub-and-spoke vcs model.  When we did this, though, we had a lot of problems with git saying we had conflicting changes on files that we hadn't actually changed.  After a few days of trying this model unsuccessfully, we found the "Working With Teams" document that advised for the alternative approach and gave up on the first approach.  At the time I assumed that the problem was caused by lots of changes being made on the same files in the hub and git not knowing how to resolve them.  Do you think our experience was a fluke and we ought to try again?  I'm totally open to a second-shot if that model should work.

Again, great work with everything.



Nov 12, 2012 at 6:17 PM

Hello Nate,

I think that the second approach above that I suggested will work better for you in team mode, where there are more than one person working in the code base at the same time, it also allows the team to collaborate using git together without having to care about what happens in TFS.

the first approach is kind of optimized for the lone developer where everyone works in TFS and there is this one developer who needs to work using git.

So I would recommend the second approach. The only disadvantage of this approach today (And we do have a backlog item to address this in the future) is that "git tf checkin" from the common repository will not maintain the changeset owner in TFS. We are working to make this better in the future.

please let us know if you have more feedback or suggestions for git tf :)



Jan 24, 2013 at 9:18 PM

I just hit this as well.  Basically I have a depot on github and a couple of different clones on different machines.  I was hoping to be able to go to any of my github clones and use 'git tf configure / git tf checkin'.  It's looking like I can only do this from the first repository.

My hope was that we would use Github for our project / community management and use hosted tfs as our CI / buddy build service.  It looks like this design is going to cause us to go down the 'you must check into a central repository before you can buddy build' route.

Am I understanding things correctly?

Feb 4, 2013 at 7:31 PM
Hello jaybeavers,

Sorry for the late reply.

The best way to solve the issue you are having is to commit/push to a central repository that is synced with TFS using git-tf.