Synchronization of two TFS?

thanks for your answers.
would you describe what has to be done in more detail? is that possible?
i need it to work on a two way basis (if i understood you correctly.)
i have change x on server a & change y on server b and the result should be changes x&y present on both servers a&b ...

thanks & regards,
rhapsy

Rhapsy at 2007-9-10 >

I believe some of this is dependent on what exactly the scenarios you are trying to accomplish. If this is the same code base \ projects then you are probably not going to be able to do this, since you won't be able to automatically merge changes between the 2 sources reliably. If its different code bases then Luis's event model subscription would be a way of getting near real time. Additional you could just create a timed event that would us the tf command (or similar programatic approach) to get latest from the 2 different code bases and check them in accordingly. You could probably use a trick with using 2 workspaces in order to do this:

Server A -> Checkout everything from 1st Workspace
Server B -> Get Latest from 2nd Workspace
Server A -> Check in code
Server B -> Checkout everything from 1st Workspace
Server A -> Get Latest from 2nd Workspace
Server B -> Check in code

Once again, this only works in simple scenarios. Anything complicated will have to be merged by hand

kayers at 2007-9-10 >

Writing a service to do this is going to be a bit trickier then it may seem but it's not an insurmountable problem. What it really comes down to is defining what operations will be supported and how they will be mirrored ahead of time. I'm not trying to state the obvious by saying "think of the requirements first" but in this case an iterative design approach may cause some real pain later.

Some issues you will need to think hard about are:

1. Will you be mirroring the entire repository, a single team project or an arbitrary set of spaces within the repository?

2. Document how you are going to handle every possible change type (If life were as simple as "add", "edit" and "delete" this would be trivial):

a. Rename is a small pain (you need to know not just the new name but also the old name and there are some complex rename scenarios (rename a b, rename b a, checkin)).

b. Undelete has similar problems to rename.

c. Merge and branch are a larger pain - in RTM there is not a reliable method of determining what the source item of a merge or branch operation was - you only know the target. I've talked about this issue quite a bit on my blog (http://blogs.msdn.com/RobertHorvick - “Discovering TFS merge history using the client API” parts 1-3). You can mirror merge/branch operations as add/edit/delete but you lose the integration history which might be important later on. Also you can't tell what resolve operation was used so you need a method to make sure you do the right thing there.

d. Complex operations ... consider change types like: merge+rename+edit+undelete+encoding+lock

e. Will you mirror security?

3. How will conflicts be handled? A conflict in this case is a file that was changed in both systems since the last time the service did a mirroring operation.

4. If you have a work-item link to a changeset in one system how will you find the right change in the new system?

5. How do you avoid mirroring changes that were added as the result of a mirroring operation?

6. TFS operates best when fed recursive operations ... but the server expands those so do you invest the time into trying to find the recursive most operation to run? What happens if you compress operations wrong? What happens if you don't compress operations at all?

7. What happens when a mirroring operation fails? Do you manually recover from this - and if so how? Once you've recovered manually how you let the server know that it should not process the changeset you just manually merged (or that it should re-try it even though it thinks it succeeded).

Also if this needs to be reliable (which it does) you can't use event subscription since that is not a guaranteed delivery mechanism (and delivery order can't be guaranteed either and that is really important). So this probably needs to be a polling application.

It turns out polling is easy to do wrong. One "obvious" solution is to call QueryHistory in a loop ... but down this road is pain and performance problems. There is a much better approach that involves calling GetChangeset not once - not twice ... but as many as three times (each with different levels of detail).

Please don’t get the impression I’m trying to scare you out of doing this. Quite the contrary – I want you to be successful at it. Properly scoped and thoroughly considered – writing a migration engine is a very doable task.

Robert.

[post edited to fix small font]

RobertHorvickMSFT at 2007-9-10 >