I have a main line called "Main" and a "Dev" line. Dev is child of Main.
Main
^
|
Dev
Actually, Main is used as a normal Dev branch, so both are checked-in new work continuously.
From time to time, we decide to merge both. Pull Dev changesets to Main and the other way around. I guess we've not doing this correctly. We change files during merges, etc. In one situation we have created a branch from Dev to stabilize. Guess this was a mistake.
The problem is, some changesets are "persistents", they keep showing up in merge window, also in "tf merge /candidate" command, as if they weren't merged already.
I guess I could do a tf /discard and that would make the changeset disappear. Shouldn't it be this way?
What is more, sometimes a merge reappers or even disappers after merging another changeset. Guess it is a somehow related changeset from another merge operation. In the course of getting rid of these, one single changeset is merged more than once.
PS: Have tried tf /discard, tf /discard /baseless, tf /baseless handling conflicts. Nothing works. Did not try /force because I'm not keen on redoing all conflicts AFAIK.
It looks to ne like you are suffering from the pick-n-mix anti pattern.
http://nakedalm.com/avoid-pick-n-mix-branching-anti-pattern/
Change your branching method and the issue will go away.
Since I could not merge in the reverse direction (as mentioned in another solution), I tried to solve this in another way.
I rolled back the merge, checked in, and merged again. This time, trying to make no invasive changes.
I did have to 'change' the project file, since the merge tool listed a single chunk of lines that I needed to merge partially. So I excluded the chunk but manually copied the lines that I did need, still inside VS's merge tool, during conflict resolution. Then I accepted the resolution.
During my first attempt, I had left out these lines completely, causing some files and folders to be wrongfully excluded from the project. Then, in the Solution Explorer, I had re-included those files and folders.
Somehow it seems that my first attempt caused TFS to see the merge as incomplete, leaving it in the list. My second attempt was seen as a complete merge and successfully swallowed the candidate.
You shouldn't need to discard changesets. If you want to "sync" them, just merge MAIN->DEV, then DEV->MAIN, potentially resolving conflicts at both steps.
After that no changesets should show up in the merge list and they should be in sync. If this isn't happening for you, we need some kind of reproducible scenario or detailed description of a specific scenario so we can help you out.
Related
Background:
I have run into the problem that half a year later some code is missing.
I have tracked down the culprit to a certain changeset.
Now this changeset contains about 7000 files (after filtering) and that is a tad too much to go through.
Question:
I would like to see a list of all the files in said merge that had a merge conflict and required manual assistance.
Is there a way to retrieve it now or is it gone like tears in rain?
Its gone like tears in the rain... But there is hope.
If you create a branch from the changeset before the merge then re-run the merge you should get the same conflicts.
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!
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.
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.
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.
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.
When I merge files from one branch to another and then go to check in files into the target branch, there are MANY files checked out, just the ones that changed. For example, Main and Critical branches were the same and we made changes to only 2 or 3 files on the Critical Fix branch. I then merged Critical ==> Main, and when I went to check in changes to the Main branch I noticed that there were numerous files checked out, not just the 2 or 3 that were actually changed in the Critical Fix branch. Moreover, when I compare a file from the Main branch to one on the server, I am told that the files are identical. If the files are identical, why are they checked out? Any help would be appreciated, or even a link that explains how TFS 2010 does merges.
The default Source Control Merging tools in Visual Source Safe and then TFS have always been rather poor - they are often confused by the simplest changes, often detect identical files as being "changed", and the auto-merge facility frequenty fails (includes the wrong changes). I quickly learned distrust for these merge tools (in about 1995) and have not seen any evidence in any of the new releases since then that the core merge algorithms have been improved at all.
The good news is that you can replace the client-side merging tools with third party ones (I use one that works so well that I actually trust its auto-merge option. I once spent 2 days trying (and failing) to do a complex merge with the TFS tools and in the end bought this 3rd party tool and re-did the entire merge successfully in 15 minutes!)
The bad news is that the first step of branch merging just uses the TFS merge code, and so it gets confused a lot, resulting in the symptoms you've described. This is frustrating in such a key feature of such an expensive application as it wastes a lot of programmer time on every merge to fix imaginary "conflicts" - on the plus side, with the help of 3rd party tools it is usually very easy to reliably resolve these merge issues.
I have had the same problem. I created a branch of our DEV branch and made changes to a few files. I checked in my changes and merged the latest changes to DEV into my branch. After the merge all 30,000+ files in my branch were marked as changed. Just like cju, I found that a comparison of most of the files showed that no changes had been made.
I decided to undo all changes and try again. When I right-clicked on the solution and selected Undo, I got a message that one file had changes, was I sure I wanted to undo that file? I clicked "No to All" and when the undo operation was complete, only the files that had been changed during my merge from DEV were still checked out. This was exactly what I wanted so I checked those changes into my branch and continued working.
I hope others can correct their situation as easily as I was able to.
One thing I noticed is that when one file is changed in different branches resulting in exactly the same content, then merging marks it as a conflict since the file is changed in both places. Of course a difference view of the file notices that there are no changes and therefore an auto merge solves this automatically for you.
Imagine the following situation: I have two branches: DEV and MAIN. I'm working on a file in the DEV branch called program.cs. I checked it in multiple times, so I end up having a couple of changesets: for example 5900, 5905, 5909. Please note these are not contiguous.
Now I want to merge these changes to MAIN, but without checking in each changeset in between. This isn't possible because: the first merge works, but the second merge of the changeset gives me the following error:
TF14085: Cannot merge $/DEV/program.cs to $/MAIN/program.cs because there is an incompatible pending change (not edit or encoding) at $/MAIN/program.cs already.
Is there any way to get around this error? Is Visual Studio 2010 behaving the same (I will probably have the chance to try this out later today)? How does TFS do this when merging multiple, but contiguous changesets?
You need to check in the current changes then redo the merge. I have had the same issue and unfortunately the only way around is to check-in between merges.
Our project has hit a point where we need to split off some code into a separate team foundation project. We would like to move these files so they retain their version control history. Temporarily we are copying the files back to the original team foundation project and re-adding them just so that our daily build & test process doesn't break. As we are able to modify our build & test process we will start to remove these temporary copies.
One issue we are noticing is that we have a nightly script that checks various maintenance branches to see if there are changesets that haven't been merged back to trunk. It is now whining about changesets that have been merged before. These changesets seem to be related to the files that have been moved and re-added. Any ideas as to why we are seeing this and how we can discard these merge candidates? If we do a merge /discard TF tells us "there are no changes to merge". It seems to be confused. Also are there other problems we might run into with this approach? Perhaps there is a better approach?
The solution that I found was to merge /discard all other changesets, then do a "catchup" merge /discard i.e. not specifying any version info. This generated a number of merge related pending changes but when I went to check them in, I got a TF14088 error. The workaround for this error was to checkin just the problematic files/folders first and then check in everything else.