1

We have a branch called "Main". In July 2012 I created a new branch from this called "Phase 3" for the next version of our project. We have been working on this since then, but from time to time some other changes get applied to Main.

In May this year we performed a merge from Main to Phase 3 with some of those changes, and that was all fine.

Between then and now, we upgraded our TFS server from 2008 to 2012 update 3. (I wasn't involved with the "upgrade" but I believe it was an install on a new server with some kind of backup/restore of the data.) We've bit had any other issues with this.

Last week I tried to perform another merge from Main to Phase 3. I chose "selected changesets" because we have done a serious amount of rework in our phase 3 branch so merging changes across is quite difficult - so I wanted to do them bit by bit.

However, I was surprised to see that Visual Studio was trying to merge across changes from July 2011 - a good year before the branch was made (the very first changes made to this part of our project in fact.)

Oddly enough, if I view the history of the phase 3 solution I can expand it and see all these changes. So TFS appears to know that they have already applied.

I tried to merge some of the earlier changes across to see what would happened. The only changes it included were to do with items that had been renamed or deleted. For example, we had renamed our solution so TFS wanted to branch and merge a copy of the SLN with the old name. Or we had some images that had been subsequently deleted in both branches, but not at the time of this new merge.

So I backed this out and tried to merge everything across from May this year - i.e. just before our last merge across. This carried over a hideous number of changes - all sorts of things including regular merge/edit type changes. So I backed that out too!

We had created another branch from Phase 3. I have been able to merge between the two branches OK. I think it was created about a week before the TFS upgrade. But it's not experiencing the issue.

We have other branches that were taken from Main. These are experiencing the issue in that TFS is wanting to apply changes that it has already made.

I am using VS2012 update 3 to do the merge. I also tried VS2010 just in case but that does the same. Also a colleague has tried it and confirmed the same symptoms.

I don't think it helps that our phase 3 is so vastly different to main that merging anything across is really difficult.

Does anyone know how I can best resolve this? I'm a little worried about doing something I might regret later on!

John
  • 37
  • 5
  • 1
    This is not an answer, but merging and branching in TFS is a huge problem, you're only going to get more such problems as time goes on. The best advice to avoid these problems is in fact to switch away from TFS and go for competing VCS tools. – Lasse V. Karlsen Aug 12 '13 at 09:20
  • That's not really an option for us at the moment as the organisation has too much invested in TFS now. We have been using TFS for source for years now and never really had any issues before this. (Well nothing that we haven't been able to live with.) – John Aug 12 '13 at 13:26
  • there is a reason MS took to implementing git as an option for their TFS SCM engine, even though its not 'true' git, having a few compromises to fit it in with the TFS way of centralised storage. embrace... :) – gbjbaanb Aug 12 '13 at 21:52
  • 1
    @gbjbaanb: I have no idea what you're saying with "not 'true' git" but it absolutely is a proper git repository. You have the choice to use centralized TFVC *or* proper, git DVCS in TFS 2013. – Edward Thomson Aug 12 '13 at 22:12

2 Answers2

4

I encountered similar problems when upgrading from TFS 2008 to TFS 2010. The issue is probably due to partially merged changesets. I.e. some of the files in the changeset have been merged, some haven't. Or it could be a branch move / rename situation. See the answer here for details of why a branch rename can cause this problem

In TFS 2008 if you attempted a merge, then unchecked files from the pending changes list. TFS assumed that you didn't want to merge the file ever again and on subsequent merges you wouldn't see those files.

In TFS 2010 or higher, the behaviour changes. If you uncheck files from the pending changes, on the next merge TFS will attempt to merge those files again. I think TFS 201x has the correct behaviour but its a pain that MS didn't highlight the change in behavior.

To check if this is the case, run the following from the command line

tf merge $/tp/main $/tp/phase3 /recursive /candidate

The /candidate switch tells TFS to give you a list of changesets it wants to merge without performing the merge. If you see any changesets in the list that have a * next to them, these are partially merged.

To fix it you have 2 choices.

  1. Merge the files and resolve the conflicts, it might be worth merging on a changeset by changeset basis rather than trying to do them all at once. This will probably be a bit painful but once it's done it's done.

  2. If you're confident that the phase 3 branch is correct then you can Merge using the command prompt. If you use tf merge $/tp/main $/tp/phase3 /version:c123~c456 /recursive /discard where c123 represents the oldest changeset you want to ignore and c456 represents the most recent changeset you want to ignore. The /discard switch tells TFS to update the merge history so that it thinks the merge has been done, but it won't actually perform the merge. This should remove the partially merged changesets from your list of candidates

If you opt for option 2 then you should do some analysis to make sure that you really don't want to take the partially merged changesets.

Community
  • 1
  • 1
James Reed
  • 13,873
  • 51
  • 60
  • Yes I do get lots of changesets with a * so I think you might be right. I know for a fact that a number of the changes definitely should not be merged into phase 3 (ones created before the phase 3 branch for example) so it sounds like option 2 will be able to clear all of those out. I think with the combination of those two options I should be able to resolve it. Thanks very much for the help - you are a life saver! – John Aug 13 '13 at 07:42
  • No problem, one of the main reasons I post here is because I've been through the pain. TFS has matured in to quite a nice product but it took a while to get there – James Reed Aug 13 '13 at 10:21
0

If you get to the point where merging is too difficult, or you just don't trust it.. then the only practical option is the "stomp over it with a new changeset". ie - do the merge manually outside of TFS and then commit your new, fixed changeset. then, kill the old branch and start again.

Not an ideal situation to be in, but your source integrity is paramount. Hopefully starting from a fresh branch will prevent issues like this in the future.

gbjbaanb
  • 51,617
  • 12
  • 104
  • 148