The typical process we use is:
Write code
Checkin changes with a description of what they are
merge forward (dev to QA)
We have been working on a series of changes. Management decided they want us to move up a small set of these changes. These changes are all over the place. I can't simply merge the changes by checkin/changeset as I normally do.
The only solution I can think of is to manually copy paste the changes I do want into QA. This breaks my documentation and normal flow. But, in the future the merge tool should pickup what has already been moved forward; that is when we revert back to the normal flow.
What would you do?
If I understand you, try to use baseless merge:
Use baseless merge to merge items that are not directly branched from
each other. To perform a baseless merge, you must use the tf merge
command. When you perform a baseless merge, Team Foundation does not
have any information about the relationship of the files in the
braches. In a baseless merge, you must perform manual conflict
resolutions. After you have performed the baseless merge and resolved
any conflicts, Team Foundation records the merge history and
establishes a relationship between the folders and files.
Improvements to baseless merge in TFS 2010 SP1
You might want to look at WIMBI. What WIMBI does, is it merges by work items associated with the changeset(s).
What might work for you is to:
Associate the relevant changesets with a work item representing the unit of work (i.e. task) that needs to be ported (ideally, you would have done so when checking it in)
Create a release branch from your code from before the changes you need to merge (and before the changes you do not want to merge
Use WIMBI or cherry pick the changesets to perform the forward integrate your changes to the new release branch.
Hope this helps,
Assaf.
Related
I would like to support the following situation:
development happens on two branches - they are both a bit like "default" (actual development happens on feature branches, but they are branched of and merged to one of these two branches)
I would like to merge changes from one branch to another in both directions without grafting individual commits
branches have a diff (on big merge of a feature branch) that I would like to always keep and support
I tried to do a dummy merge as described here, first in one direction, then after several successful merges, in another direction (dummy merge of dummy merge). Now I need to do a merge again in another direction, and here another dummy merge (of dummy merge of dummy merge) does not help me any more (and I hoped that one dummy merge would be enough anyway).
Is it possible to do development in this fashion, or is it better to do most of development in one branch? (well, I know it is better for hg, but I have reasons)
Preface
If both branches share the same functionality (unstable common DEVEL), I can't see any reasons in such splitting, except added headache
Face
You can avoid merging unwanted changeset from one branch into another and use ordinary merge if you'll convert this mergeset into MQ-patch ( or maybe shelveset) and always merge from|to (read "Merging patches with new upstream revisions" for merging to branch hint) branch with unapplied patch
Perhaps I'm biased from years of svn but why would I ever want to merge with a different branch then make some changes before committing. The hg output itself suggests otherwise:
(branch merge, don't forget to commit)
Dear hg, then why didn't you just do it for me?
Because a merge operation is not guaranteed to produce correct output (automatic merges can use bad heuristics for how to deal with conflicts, manual merges can suffer from human error). Usually, what you will do is the following:
Merge.
Build.
Test.
If the test failed, fix the issue, go back to 2.
Commit.
Mercurial does not suggests otherwise, it 's just reminder: "All merge-related changes stored only on Working Dir, commit results into repository for permanent storing" and doesn't prohibit you to make some additional changes in code before commit.
But separation of tasks (merge and not-related to merge changes - i.e changes not initiated by merge-conflicts) into separate changesets is good idea anyway
I need to roll back a merge operation in TFS2008. The branch will need to be merged at a later date. I know I can use the tfpt.exe rollback operation on the trunk to restore the files modified by the merge, but rollback doesn't modify the merge information so future merges from the branch into the trunk won't restore the changes undone by the rollback. Also, merges from the trunk into the branch will risk overwriting changes in the branch.
I've probably left out quite a bit of necessary information, so I'll update the question as needed.
What is the best way to undo the merge, and still be able to merge all changes in at a later date?
Thanks.
I just tried this doing it manually and when you attempt to merge after after having checked out an older version and then checking in the older version the file is still essentially flagged as already merged. I see the same exact problem when doing it without tfpt- pretty interesting.
So I took a look at the docs and it looks like what you are going to want to do is use /force. I am guessing if you do a tfpt rollback and then run tf merge it will work. If not, try manually rolling back and then running tf merge /force.
/force
Ignores the merge history and
merges the specified changes from the
source into the destination, even if
some or all these changes have been
merged before.
Hope that helps.
In TFS 2010, how can one mark a changeset so that it cannot be merged from one branch to another? For example, so it doesn't show in the "merge wizard" in Visual Studio when using the "Selected changesets" option. Basically, I want it to look like the changeset in question has already been merged into another branch.
Our build process auto-increments the version numbers in all our AssemblyInfo.cs files. A changeset in a release branch that contains only version increments should not be merged into trunk (or another release branch, of course).
I believe this is analogous to the "Only record the merge (block revisions from getting merged)" checkbox in TortoiseSVN.
I think I found the answer to my question. The tf.exe command has a switch "/discard" which is documented as "Does not perform the merge operation, but updates the merge history to track that the merge occurred." This is exactly what I was looking for. I'll try it and post an update if this not what I'm expecting.
http://msdn.microsoft.com/en-us/library/bd6dxhfy(v=vs.80).aspx
There's really not an analog in TFS for what you're trying to accomplish. Within TFS each subsequent changeset for a file is a delta off the previous changeset (and so on down to the base revision). Therefore, you can't really "skip" a changeset.
I'm not sure exactly what you mean by "version increments" in this situation. Are you talking about file/assembly version, or something else?
When SVN with merge tracking works, it's really nice, I love it. But it keeps getting twisted up. We are using TortoiseSVN. We continuously get the following message:
Error: Reintegrate can only be used if revisions 1234 through 2345 were previously merged from /Trunk to the reintegrate source, but this is not the case
For reference, this is the method we are using:
Create a Branch
Develop in the branch
Occasionally Merge a range of revisions from the Trunk to the Branch
When branch is stable, Reintegrate a branch from the branch to the trunk
Delete the branch
I Merge a range of revisions from the trunk to the branch (leaving the range blank, so it should be all revisions) just prior to the reintegrate operation, so the branch should be properly synced with the trunk.
Right now, the Trunk has multiple SVN merge tracking properties associated with it. Should it? Or should a Reintegrate not add any merge tracking info?
Is there something wrong with our process? This is making SVN unusable - 1 out of every 3 reintegrates forces me to dive in and hack at the merge tracking info.
This problem sometimes happens when a parial merge has been done from trunk to branch in the past. A partial merge is when you perform a merge on the whole tree but only commit part of it. This will give you files in your tree that have mergeinfo data that is out of sync with the rest of the tree.
The --reintegrate error message above should list the files that svn is having a problem with (at least it does in svn 1.6).
You can either:
Merge the problem files manually from trunk to branch, using the range from the error message. Note: you must subtract 1 from the start of the range, so the command you'd run would be:
cd <directory of problem file in branch working copy>
svn merge -r1233:2345 <url of file in trunk>
svn commit
or
If you're certain that the contents of the files in your branch are correct and you just want to mark the files as merged, you could use the --record-only flag to svn merge:
cd <directory of problem file in branch working copy>
svn merge --record-only -r1233:2345 <url of file in trunk>
svn commit
(I think you can use --record-only on the entire tree, but I haven't tried it and you'd have to be absolutely sure that there are no real merges that need to come from trunk)
Bunny hopping might be the solution.
Basically, instead of continuously merging trunk changes into a single branch (branches/foo, let's call it), when you want to pull those changes from trunk:
Copy trunk to a new branch (branches/foo2).
Merge in the changes from the old branch (merge branches/foo into branches/foo2).
Delete the old branch (delete branches/foo).
Your problem is that you're trying to use Reintegrate merge on a branch that has been 'corrupted' by having a 'half merge' already done on it. My advice is to ignore reintegrate and stick to plain on revision merging if this is your workflow.
However, the big reason you get errors is because SVN is performing some checks for you. In this case, if the merge has extra mergeinfo from individual files in there, then svn will throw a wobbly and prevent you from merging - mainly because this case can product errors that you might not notice. This is called a subtree merge in svn reintegrate terminology (read the Reintegrate to the Rescue section, particularly the controversial reintegrate check at the end).
You can stop recording mergeinfo when you perform your intermediary merges, or just leave the branch alone until its ready - then the merge will pick up changes made to trunk. I think you can also byass this check by only ever merging the entire trunk to branch, not individual files thus keeping mergeinfo safe for the final reintegrate at the end.
EDIT:
#randomusername: I think (never looked too closely) at moving is that it falls into the 'partial merge' trap. One cool feature of SVN is that you can do a sparse checkout - only get a partial copy of a tree. When you merge a partial tree in, SVN cannot say that the entire thing was merged as it obviously wasn't, so it records the mergeinfo slightly differently. This doesn't help with reintegrate as the reintegrate has to merge everything back to the trunk, and now it finds that some bits were modified without being merged, so it complains. A move appears kind of the same thing - a piece of the branched tree now appears differently in the mergeinfo than it expects. I would not bother with reintegrate, and stick with the normal revision range merge. Its a nice idea, but it trying to be too many things to too many users in too many different circumstances.
The full story for mergeinfo is here.
I suspect you're not following the merge instructions correctly:
"Now, use svn merge with the --reintegrate option to replicate your branch changes back into the trunk. You'll need a working copy of /trunk. You can get one by doing an svn checkout, dredging up an old trunk working copy from somewhere on your disk, or using svn switch (see the section called “Traversing Branches”). Your trunk working copy cannot have any local edits or contain a mixture of revisions (see the section called “Mixed-revision working copies”). While these are typically best practices for merging anyway, they are required when using the --reintegrate option.
Once you have a clean working copy of the trunk, you're ready to merge your branch back into it:"
I have few problems with merging.