Mohamed Mahmoud (El-Geish) : Merge

How to: View history of an item across branches?

mohamedg — Sat, 18 Apr 2009 10:01:09 GMT

You can use tfpt history /followbranches to follow the history of an item across branches. We are looking into supporting this in the history dialog in the next version . You can see which versions are ported over during the merge operation if you use...(read more)

Pitfalls of baseless merge

mohamedg — Tue, 07 Apr 2009 09:09:35 GMT

A previous post was dedicated to show the benefits of a baseless merge, this one shows the pitfalls: When you perform a baseless merge, renames and deletes will not be merged If you get conflicts, the usual 3-way merge is not possible, you will have to...(read more)

Merges

mohamedg — Sun, 22 Mar 2009 02:31:54 GMT

When you would like to know what changes have been merged already between a source and a target you can run:

tf merges sourceItemSpec targetItemSpec

Usually you would like to view the merge history recursively when you are using folders are branch roots (it’s recommended to use folders as branch roots, don’t use files as branch roots). The /r option will allow you to see merges between the folders and their child items too. If you don’t supply /r you will only see merge history of the folder itself (which usually consists of renames, deletes, etc.) and it wouldn’t be much. You can also run the command without specifying the optional argument sourceItemSpec to view all the merges that were applied to that target regardless of the source.

The output of the command looks like the following:

Changeset    Merged in Changeset    Author                                Date
---------        ------------------------    -------------------------------- ----------
120            130                             DOMAIN\userName              2/2/2009
150            200                             DOMAIN\userName              3/3/2009
…etc.

The first column shows you the changeset that was merged or ported over from source to target, and the second column shows the changeset when this merge was committed.

When you would like to view the changesets/versions that weren’t merged from source to target yet, you can run:

tf merge /candidate sourceItemSpec targetItemSpec

Again, usually you would like to use the /r option with this command too. The output of this command looks like:

Changeset    Author                                Date
---------        -------------------------------- ----------
210            DOMAIN\userName              4/4/2009
220            DOMAIN\userName              5/5/2009

These are the candidate changesets for the next merge. Merging up to the latest version will pend these changes on the target, you will see something like this:

merge, edit: $/Proj/Src/File.cs;C205~C220 -> $/Proj/Tgt/File.cs;C207

This means that you are going to merge the changes from the source between changeset 205 (the first changeset after the last merge from source to target) and 220 (latest version of source) to the target item at version 207 (latest version of target). The merge command allows you to merge cherry-picked changesets or merge up to a specific version of source. For example, if you run:

tf merge /r $/Proj/Src;100 $/Proj/Tgt

Since you specified changeset 100 (you don’t need to use the C prefix, it’s the default) it’s like requesting a merge for versions 1~100 of source which were already merged, hence, you will see a message indicating that "There are no changes to merge."

When the merge change is committed, the merge history of the target is updated, and credit is given to the merge. Next time you merge, you wouldn’t see these changes again, unless you force them to be merged again using the /force option, and subsequently they wouldn’t show up in the candidates list. Of course, the merge history will show one more entry after the merge. If you want to ignore the changes but at the same time give credit for the merge, you can use the /discard option. This will pend only the merge change without any other accompanying change, just like what happens when you resolve a conflict as keep target. Again this will record the merge operation in the merge history.

How to: Change file encoding?

mohamedg — Wed, 18 Mar 2009 07:36:22 GMT

While merging or comparing files using the DiffMerge tool, and files have different encoding, you will see this message:

"The character encodings on these files are different. Only files with the same character encoding can be merged or compared."

If you look at the properties window of a file in the Source Control Explorer or run tf prop itemSpec, you will see the encoding of the file as stored on the server the last time the encoding was set either explicitly using the /type argument during tf add or tf checkout, or implicitly when TFS tried its best effort to detect the file's encoding during the add operation. This encoding stored on the server may not match the latest version’s physical encoding, as someone could have checked-in the file in a different encoding or explicitly changed the encoding stored on the server. To solve this issue, you can detect the encoding using the properties dialog or set it to match the file’s physical encoding if you know it. The other thing that I can think of is that the encoding of the local files that we are trying to merge has been changed by a tool or an IDE. Open both files (source and target) in Source Control Explorer, detect and save their encoding, open the target file locally using Visual Studio and Save As With Encoding to make it match the merge source encoding.

How to: Merge items that were not branched?

mohamedg — Wed, 18 Mar 2009 07:20:00 GMT

This post is not about merging an existing item to an non-existing one, which will be a (merge, branch) change. This post is about merging items that already exist but they were not branched. One of our customers had this problem, he had three branches: A –> B –> C and he needed to port some changes from A to C. Unfortunately, his team copied the files from A and added them to C instead of merging the changes from A to B then from B to C. So, he ended up with the same contents but without the branch or the merge relationship. The solution for this problem depends on what version you’re running. If you are running TFS 2005, then you need to merge A –> B –> C and this will result in Filename Collision conflicts, then you’ll need to undo the conflicting changes and do a baseless merge for each item. If you have many items, you may want to use a FOR loop that reads the inputs from text files:

FOR /F %i IN (undo.txt) DO tf undo /i %i
FOR /F "tokens=*" %i IN (merge.txt) DO tf merge /i /baseless %i

If you're running TFS 2008 or later, we do the baseless merge for you implicitly.

Note that if the merge relationship is already established between source and target items, you wouldn’t want to use /baseless because it implies /force. Baseless is useful when you want to merge without referring to a base version, and it establishes a merge relationship between items that don’t have it already so that future merges don’t need the /baseless option. Baseless merge implies /force because it means that there’s no merge history and no base version.

Conflicts

mohamedg — Thu, 12 Mar 2009 05:36:20 GMT

To understand conflict types please read this article on MSDN. In this post I’ll focus on conflicts that need you to manually merge the files. Let’s rule out binary files first because TFS doesn’t compare them, and doesn’t store deltas of them, it stores the whole file every time it’s checked in. TFS treats all types of text files the same, no special handling for C#, XML, SQL, etc. The diff algorithm wouldn’t know if the change is in a method, a stored procedure, a tag, or is a comment. It’s just text for the diff algorithm but encoding plays a part when it’s not the same for both files. In this case, TFS will fall back to a common encoding (UTF-16) before comparing the files. While merging, TFS applies the changes automatically if they don’t conflict. If the changes you are merging are made in areas that are adjacent or share common lines, then the AutoMerge option won’t be available and you’ll have to intervene to merge them manually. TFS is more careful when it auto-merges changes and that’s why it wouldn’t auto-merge adjacent changes. If you are using a third-party diff/merge tool, YMMV.

How to: Use tf merge /discard?

mohamedg — Mon, 09 Mar 2009 07:36:49 GMT

In a previous post, I mentioned some details about merge history bookkeeping. In a nutshell, when you merge, you are giving credit to the target branch for the range of versions you’re merging over. That’s why you see the merge change type pended on the target items, because it means that this will be recorded in the bookkeeping system, or merge history, when you commit this change so that you don’t re-merge the same versions/changes next time. However, sometimes you just need to record that merge in merge history without merging over the actual changes. This will give the target branch credit for these versions and discard porting the changes over. You guessed it right, that’s when you use tf merge with the /discard option then check in to commit the merge operation.

Note: If you use TFS 2008 SP1 and run tf merge /baseless /discard, there’s a known issue that was fixed here.

How to: Merge up to a specific version?

mohamedg — Sat, 07 Mar 2009 08:32:17 GMT

Merging is transferring changes from merge source to merge target, just like any transaction, it’s based on the debit-credit system. Now let’s say that we built up some changes in the source branch, these will show up as merge candidates because these changes weren’t merged over yet; the balance is not zero. With this bookkeeping system, TFS records merge history so that every time you merge a change it’s recorded and it doesn’t show up again in the candidates list. If the balance is zero, this means that there are no changes to merge. This usually happens when both branches are at the same version, and one way to accomplish that is to merge all changes up to the latest version, which is the default for the merge command. However, this is not always the case. Most of the time you would like to branch from a good version; one that was bug free or a milestone, and that’s why the merge command has the /version argument, to specify which version you’d like to merge up to. You may also specify a range of versions, which may help speed things up if you know your base version as you can specify a range from the base version to that good version.

How to: Port a specific changeset?

mohamedg — Sun, 01 Mar 2009 07:00:36 GMT

Merge enables you to specify a range of versions to merge over. This means that you can merge a range of versions without the need to merge previous versions. For example, if file foo is at version 10 in the source branch and is at version 6 in the target branch. If you want to port changeset 9 only without porting all the changes up to that version (i.e. you don’t want to port 7 and 8 along), you can specify that in the version range:

tf merge /version:C9~C9 $/proj/source/foo $/proj/target/foo

On a side note, when you append the ;C123 to an item spec while merging, this means that merge will be scoped to only the items that were changed in C123.

Merge Change Type vs Merge, Branch Change Type

mohamedg — Sun, 01 Mar 2009 06:26:38 GMT

While merging merging branches, you may see change types like "merge" and "merge, branch". When you merge an item to a non-existent namespace, this will be a (merge, branch) change type. A (merge) change type occurs when there's a conflict to be resolved and we don't know what other changes may be pended until the conflict is resolved, or when there's no change to neither the file content nor namespace, but the merge history will be updated to establish a merge relationship between source and target or update the latest version merged.