As with most things in TFS you get more than you bargained for. In this case I am seeing more file changes during the merge than I was expecting.
I have 2 child branches, lets be exciting and call them branch1 and branch2. Both have changes made to them since they were created. I need to take 12 specific changesets from branch2 and merge them into branch1. The changes from branch2 can not go back to the parent branch. So it's a straightforward case for a baseless merge, but the results are not what I expected.
Taking the first changeset I ran the following command:
tf merge /baseless /recursive /version:C95654 branch2 branch1
Changeset 95654 contains 12 changed files but after this command I get 56 edited files with conflicts. I was expecting to only merge the specified changeset from one branch to the other but it appears to have merged the entire folder.
So why do I get 56 files changed rather than 12 when I specified the changeset? Also what can I do to restrict what is merged to only the contents of that changeset?
If you need to merge a specific changeset you need to use the following statement:
tf merge /baseless /recursive /version:C95654~C95654 branch2 branch1
(It means ONLY changeset C95654).
The commandline you are using means every changeset before and with C95654.
I had to use tfs paths for the two branches. Steps were: add both branches to the desired workspace; get latest; open a Windows powershell in the target folder. Get tfs paths
>tf workspaces /format:detailed
>tf workfold
Then use $paths for the branches. Same changeset number between the tilde ment baseless merge for one changeset.
>tf merge /baseless /recursive /version:C999~C999 "$/MyRepo/Current" "$/MyRepo/Development"
More here --
http://blogs.msdn.com/b/bharry/archive/2011/08/31/merge-enhancements-in-tfs-11.aspx
Related
According to the documentation for the tf merge command, using the /discard flag:
Does not perform the merge operation, but updates the merge history to
track that the merge occurred. This discards a changeset from being
used for a particular merge.
But for the life of me, I cannot get the command to do that. I have several changesets that were checked into our Develop branch that for one reason or another should not be merged into our Master branch, but when I run the command in VS 2017 Command Prompt, I get a message stating something like:
Resolved C:\source-path\file as KeepYours
In my Pending Changes window, it looks the same as if I had just merged the changeset through the UI. I've tried combining the /discard flag with several other flags - /baseless, /force, /recursive - but to no avail. Am I misunderstanding something here or is there some sort of bug?
The situation:
Several branches I constantly have to merge between them. Each branch has a special file that identifies the branch (with certain settings for commit mails, plugin options and more, doesn't matter here).
The problem:
Whenever I merge one branch to the other and this special file has been changed it will obviously overwrite the merge target file. But I don't want this to happen. Those files must be version controlled in their branches as they are an essential part of it, but they should not be merged at all as they contain branch specific information.
The question:
Is it possible (and how) to exclude a specific file from a merge? I'd like a solution that doesn't requier me to specify this on each merge as a paramter, but if there's nothing else then I bite the bullet.
The only way to exclude a file from a merge is to revert it right after the merge, before you commit, for example:
cd /path/to/repo/trunk
bzr merge ../branchA
bzr revert file/to/exclude
bzr commit -m 'merged from branchA'
Later, when you merge again from branchA, the bzr revert step in the middle is only necessary if the file changed in branchA since the last merge. So if the file doesn't change very often, then "biting the bullet" might not be all that bad.
Me and my friend need to develop a project parallely. how to do this?
I created two branch worked on each leaf. Tried to merge the leaves but getting conflict error for edited file. What is the way to merge them?
I would like to know if it possible to have 2 leaves in a single branch? If so then how to create a new leaf in addition to the default leaf.
Each branch has one leaf at any time. These represent the most recent state of the repository from the perspective of each branch. As your post mentions, branches are used to afford parallel developments within the repository. They are also created automatically (called a "fork" in such a case) to prevent two commits to same branch when each commit has the same immediate ancestor... allowing this would be just like having multiple leaves on the same branch.
To create a new branch of development, one opens a fossil repo and executes a command like:
fossil branch new some_feature trunk
Complete example
For the sake of example, I quickly created a new repository and added a single file to the trunk (the only branch initially), file.txt. The initial contents of my example file are:
here
is
a
file
After committing the added file with the comment, "create baseline", I created a development branch for a new feature called "some_feature" based on the current state (aka the leaf) of the trunk branch...
fossil branch new some_feature trunk
Now there are two branches, trunk and some_feature. Creating the branch does not change my working branch, so I am still in trunk. Then I edited the baseline file to:
here
is
a
file
folder
...adding "folder" to the end. Then I committed the change to trunk with the comment, "modification on first branch... trunk. Then I switched development to the some_feature branch...
fossil co some_feature
From this second branch, I also edited the last line of the baseline file:
here
is
a
file
reader
...adding "reader" to the end. Then I committed the change to some_feature with the comment, "modification on second branch... some_feature".
To merge development, you chose the branch you want to merge changes into. In this case, I will merge the feature branch changes into the trunk. To do this you must first checkout the destination branch for the merge... in my case, trunk.
fossil co trunk
Then, I merge in the change from the specific commit of the other branch. In my case, I'll use the leaf of that branch:
fossil merge some_feature
MERGE file.txt
***** 1 merge conflicts in file.txt
WARNING: 1 merge conflicts
"fossil undo" is available to undo changes to the working checkout.
This leaves me with four files now in my working directory instead of one. No new commit/checkin has actually made it back to the repository proper. The four files are: file.txt, file.txt-baseline, file.txt-merge, and file.txt-original. "file.txt-baseline" is the file as it existed in the most recent common ancestor of the merging branches. "file.txt-original" is the file as it existed in the target brach, in my case, trunk, just before the merge. "file.txt-merge" is the file as it existed in the branch you were merging from, in my case, some_feature. Finally, "file.txt" contains the contents of the baseline file with conflicting changes from the original and merge files annotated so you can decide how to deal with the differing contents.
In my case the generated conflicts file, "file.txt" looked like this:
here
is
a
file
<<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<<
folder
======= COMMON ANCESTOR content follows ============================
======= MERGED IN content follows ==================================
reader
>>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Until the merge conflict annotations are removed from the file, fossil will not let you commit (or it will at least warn against it). Otherwise, you would make a commit with message, such as, "merged some_feature into trunk".
For reference, here is the event history diagram as provided by fossil for this example:
How can I resolve this merging issue ?
My project has 1 branch which I used for production and head. 2 times it worked merging production branch into head. Each time I created a tagged head after merging to have a start point for the next merge. Its important to note that I do not create a new branch after each merge, I reuse the branch.
The problem is, if I try to merge my branch to head. eclipse cvs acts like it is comparing and listing all files as "to update", even if file head version is greater than the file branch version.
ex: head file version is 1.8 and branch file version is 1.6. This file was already merged in last merge. When trying to merge I specifiy as "common base version" the head tag that I created after the last merge. Still, eclipse cvs suggests to override head modifications and use the branch version. This behaviour applies to all files.
I dont know what to do. I dont want to manually merge hundreds of files.
thanks for any help
Look at the example:
|tag_h1 |tag_h2
-----------------------------------------> trunk
\ ^ ^
\ / /
\----------------------------------> my_branch
|tag_b1 |tag_b2
On branch there are tags tag_b1 and tag_b2 before each merge, and in trunk, tags tag_h1 and tag_h2.
For a next merge from branch to trunk, the "common base version" of Eclipse will be the one tagged with tag_b2. With CVS update, if you specify two parameters, you will get modifications between these two merged in your working directory. Giving Branch or version to be merged (end tag)=my_branch and Common base version (start tag)=tag_b2 will merge changes from tag_b2 until my_branch end, like calling CVS from command line:
$ cvs up -j tag_b2 -j my_branch
I always tag from where I will merge, and before and after the merge, like this:
|tag_before |tag_after
--------------------------------->
^
/
------------------------------>
|tag_from
Giving the tags a name I can recognize.
I goofed up a merge. I'd like to revert then try again.
Is there a way to revert a merge before it is committed?
hg revert doesn't do what I'd like, it only reverts the text of the files. Mercurial aborts my second attempt at merging and complains original merge is still uncommitted.
Is there a way to undo a merge after an hg merge command but before it's committed?
hg update -C <one of the two merge changesets>
After you do hg merge, but before hg commit, your working copy has two parents: the first parent is the changeset you had updated to before the merge and the second parent is the changeset you are merging with. Mercurial will not let you do hg merge again as long as your working copy has two parents.
You have two options on how to proceed:
If you want to abort the merge and get back to where you started, then do
hg update -C .
This will update the working copy to match the first parent: the . always denotes the first parent of the working copy.
If you want to re-merge some files then do
hg resolve fileA fileB
This will re-launch the merge tools just as when you did hg merge. The resolve command is good if you find out at hg merge-time that your merge tools are configured badly: fix the configuration and run hg resolve --all. You can run hg resolve as many times as you want until you are satisfied with the merge.
Today there is hg merge --abort. See hg help merge.