- Nov 16, 2012 at 2:54 PM
- Shawn Wildermuth
- 7 Comments
Very short post today, but wanted to share something that happens more than I'd like to admit. I work for some clients who use TFS and when I can't in through their VPN I need to zip up my files for them to check-in manually. It's not fun (I miss being able to create a change set in Mercurial or Git). When this happens I need to have a quick way of copying all the files in a project that aren't marked as read-only. Robocopy to the rescue:
robocopy %1 %2 %3 /S /XA:R /XD obj bin packages backup _UpgradeReport_Files /XF *.suo *.vssscc *.user *.vspscc
This allows me to copy all the files I'm working on while skipping the temp files (e.g. obj, bin), package chagnes, backup files and upgrade files. Hope this helps anyone else that runs into this.
Comments
Seems like you could keep git-tfs and/or git-tf around for such situations?
GitTFS is your answer.
GitTFS and git-tf are interesting but not if I can't get the client to agree.
@Shawn:
Not sure I understand the "can't get the client to agree" part?
They don't run git themselves, they just run TFS - the only place git runs is on your machine. AFAIK, from the perspective of their TFS server, things don't change. git-tfs and git-tf just allow you to use git to manage your local changes instead of robocopy.
IOW, AFAIK the 2 'offline' options here are 'do local versioning via robocopy' or 'do local versioning with git', so it seems like a clear win for git-tf{,s} AFAICT?
You then get the additional benefit of being able to use git all the time (not just when offline) and stop having to deal with read-only files (also fixed with TFS 2012 and Local Workspaces, but I'm guessing the client doesn't have TFS 2012 yet), which it sounds like would be a useful change for you?
Am I misunderstanding something?
Thanks!
James,
You're not misunderstanding...I clearly am. I'll check it out.
Wouldn't the client then need to expose the TFS server via an external url for git-tfs to work? I am making a large assumption that is why he is required to use vpn, because the client does not expose tfs externally for whatever reason.
If that is the case, regardless of whatever client he uses when vpn goes down he will have no repository access.
Of course they could expose their TFS like so http://msdn.microsoft.com/en-us/library/aa833873.aspx then you could use whatever client made you happy.
git er dun Friday, November 16, 2012
Seems like you could keep git-tfs and/or git-tf around for such situations?