tags:

views:

99

answers:

2

I'm a consultant whose client runs a TFS 2005 repository. I manage my own source code in TFS and deliver my releases to their TFS. My source code is around 20,000 files that I maintain.

My normal process:

  1. Detach my solution from my TFS

  2. Connect to their TFS

  3. Checkout the entire project

  4. Overwrite my project files with theirs

  5. Check everything back in

  6. Click the add button and add any new files that have been added

  7. Check everything in

  8. Open the solution file and bind it to TFS

  9. Check everything back in

The main problem I'm seeing with this approach is if I delete a file on my end, I don't have a way to reflect that change.

I'm also not interested in synchronizing tools because I don't want to synch every checkin, just the current state.

Is there a way I can do this better?

A: 

Have you looked at TimelyMigration? (No affiliation and I've never had need to use it)

TFS to TFS migration

Mitch Wheat
A: 

What about maintaining parallel .sln and .proj files with the different bindings? Do they change often?

I think you can maintain change history by using the TFPT ONLINE command from the Team Foundation Power Tools.

  1. Open SLN_A
  2. Make changes (VS auto-checks out against TFS_A)
  3. Before checkin on TFS_A, run TFPT ONLINE against TFS_B. This should pick up adds, edits, deletes.
  4. Checkin SLN_A on TFS_A.
  5. Checkin SLN_B on TFS_B.

Only problem with this might be that the SLN_A checkin could screw up the SLN_B pending changes b/c the files will be returned to read-only. Not sure.

Why do you need to maintain a parallel TFS? Seems like you ought to be working directly against their TFS, either on a branch, via the Proxy, or both.

Aidan Ryan
That won't maintain any change history or check-in comments though, and they might be required...
Mitch Wheat
I have a few reasons for not working against their TFS: contract, network reliability, authentication, creating users etc.I'm only looking for point in time change history. Checkin comments are also not required.I am worried about the orchestration. I have a dozen or more developers on this project who may or may not be checking in the SLN throughout the day.
itchi