4

We have a couple of developers who are in favor of the manual merge in TFS 2010, it's when you open two visual studios, one with the source branch and another one with the target branch and you manually copy&paste your changes.

They do it this way because they believe an automatic merge is dangerous (as it bring in changes of other developers even if you did not want to). And the typical test case is following:

Source Branch:

TestFile.cs
Changesets:
1. Line 5 changed
2. Line 13 changed

Target Branch:

No changes yet.

Now I would like to merge only changeset #2 for the TestFile.cs

What lines would the resulting TestFile.cs in the target branch contain if merged automatically: the original line 5 and the changed line 13 or both lines 5 and 13 changed?

In fact I have seen both variants and I don't know why.

Any link to a great description of how exactly TFS merge works would be great to have.

Advanced scenario: Source Branch:

TestFile.cs
Changesets:
#1. Line 5 changed, Line 6 added
#2. Line 13 changed

Target Branch:

No changes yet.

If I only merge changeset #2 what should I get in the target branch? Will I only get the line 12 changed according to the changeset #2.

BanditoBunny
  • 3,658
  • 5
  • 32
  • 40

1 Answers1

5

If you select to merge, the following dialog will open up:
enter image description here
If you simply select "Next" and preserve the default setting = "All changes up to a specific version", TFS will take into account both of your changesets (1 & 2): in other words it will check out Testfile.cs in the Target Branch and edit both Line 5 & 13.
If you select "Selected Changesets" (as marked in the picture above), another dialog will appear where you get to choose which of the candidate changesets you actually wish to participate in the merge. So, if you now select changeset 2, TFS will check out Testfile.cs in the Target branch & edit only Line 13.

What you describe as 'manual' merge, is - sorry for being verbose - a horrible practice.

Edit
On your question Advanced scenario: Source Branch: Will I only get the line 13 changed according to the changeset #2
The answer is a definite "Yes".

One way to isolate the situation is to start with a Playground-folder within SourceControl & try with your colleagues to identify what happens. TFS-merge is really straightforward, this older post might be useful for your investigations.

I can agree on you stand "TFS bugs are very low on my priority list", on the other hand - in your place - I would investigate as a top-priority issue the Merge-Practice within your organization. What you describe, in my opinion, simply cannot go on.

Community
  • 1
  • 1
pantelif
  • 8,524
  • 2
  • 33
  • 48
  • The problem is while selecting only one changeset I was getting changes which were not the part of this changeset. However it is not always the case, in fact it happens only sometime and I do not know why (partly caused by horrible practices), but there is another problem. I am trying to understand TFS merge on the low level in order to get enough arguments to forbid horrible practices. – BanditoBunny Mar 30 '12 at 11:52
  • "changes which were not the part of this changeset", that's not possible in my opinion. If you experience such situation, either it's a TFS bug you should report to MS - or it's a result of misuse. – pantelif Mar 30 '12 at 11:59
  • I've seen in it with my own eyes just yesterday. As TFS bugs are very low on my priority list, I am not going to test it further. My problem is that "manual merge" guys use this as a justification for their practice. And I want to understand what can cause such behavior, my first idea would be that the unmatched changesets are the reason TFS cannot process the merge properly. Another idea would be that structural changes in the file (new lines, removed line) + selective merge based on changesets causes TFS to malfunction. – BanditoBunny Mar 30 '12 at 12:05
  • Are you using TFS 2010 or an older version? Because the ability to merge individual changesets was greatly enhanced in 2010. Prior to that, it was very common that TFS 'had to' incorporate earlier changesets - often leading to incorrect code. Anyway, I concur with pantelif, your current merge practice is in my opinion very risky and does not allow for parallel development - the very reason to have branches in the first place. If what you have now is flawed, I 'd suggest starting a new branch from a code base the developers deem correct, and start using TFS merging from there. – Torbjörn Bergstedt Mar 30 '12 at 14:54
  • We are using TFS 2010. Starting branch from the scratch has crossed our minds :) – BanditoBunny Apr 01 '12 at 21:53
  • The problem I know how TFS work (I thought) and I am always using auto merge myself. The problem, while merging a single changeset I noticed changed merged in which belong to the other changeset, that started worrying me. In theory a merge is completely changeset based, however there is a backup strategy (looks like file based), I am looking for what might activate this strategy, so we know and can avoid it. – BanditoBunny Apr 01 '12 at 21:55