I have the following stream structure:
Parent-+->Child1
|
+->Child2
There are changes that were promoted from stream Child1 to stream Parent and broke build of the stream Child2.
I need to revert these changes only in Child2.
Exactly I need to do the following (Gig-style):
Get a diff over the transaction that broke the build (in inverted way)
Apply it to stream Child2
Locking of the Child2 to the transaction is not a variant, because there are some changes that were done after the broken transaction was made.
Hang a workspace off of Parent. Right click on the Parent stream -> Show History -> Select transaction you wish to revert -> Click on Revert. Choose the workspace you hung off the Parent stream. Once the subtractive merge completes, hang this workspace off of Child2 -> Update workspace -> Promote changes. You have now removed the bad transaction from the Child2 stream.
Related
Can safely delete a parent branch? I have a branch structure as follows:
Branch A
Branch B
Branch C
Branch D
Branch A is redundant & un-needed. Can I delete it without affecting Branch B & it's children?
Yes, you must first reparent the child branches so that they have no parent. (to unparent them, parent them to themselves from them commandline). Then you can safely delete the old branch. As long as you do not destroy the old branch, your history will also remain available.
In the Merge window your old branch will still show up due to the historical relationship. The only way to remove that relationship is to destroy the data in the deleted branch. (Note that in order to destroy properly, you first need to delete the folder, check it in, and then destroy it. You will need to rebuild the datawarehouse of TFS for the data to update there as well).
I have a following question. Suppose I have a bunch of repositories hosted that form an hierarchy, e.g.: A -> B -> C (means A is the central repository and all the rest are it's descendants).
Now suppose I work with the clone of C. Suppose I want to get the changes not just from C, but from the central repository, so I do the following commands:
hg pull [Address of A]
hg up
That seems perfectly legal, but what happens then I commit my changes and push them to C? Not only my local modifications will be pushed, but also the modifications of central repository (if there are any). What will happen if someone will try to pull the changes from A to C? Will there be a conflict or it will merge successfully the changes A -> local -> C with changes A -> C. Will Mercurial recognize it as the same changeset or not?
The identical situation takes place if I decide that my code is stable enough and can be placed in central repository:
hg commit -u spirit -m "A local modification that is stable"
hg push [Address of A]
What will happen if I make a pull from A to C and then pull from C to my local repo again, will it recognize these changeset as originating from my local repo, or will it report a conflict and suggest a merge?
And what is the best practice in that case anyway? Performing just subsequent pulls and pushes (i.e. A<->B, B<->C, C<->local)? But the problem is that I have just access to my local repository that is clone of C. How can I make a pull from B to C if I would want to on my local machine? How does Mercurial handle
What will happen if someone will try to pull the changes from A to C? Will there be a conflict or it will merge successfully the changes A -> local -> C with changes A -> C. Will Mercurial recognize it as the same changeset or not?
The changesets that already exist in C will be seen to already exist because their IDs will already be present. This is why changes are immutable. If you could modify a changeset it's ID would change (The ID is a hash of the changeset contents). Mercurial then (correctly) sees it as a different changeset. By keeping the changesets immutable we can be sure that their hash will be the same whichever repo they come from.
pull = copy changesets from over there that have IDs I haven't seen
push = copy changesets to over there that have IDs they haven't seen
Will there be a conflict
No
or it will merge successfully the changes A -> local -> C with changes A -> C.
No merge takes place because they are the same changes. It just sees that it already has them.
Merges don't happen unless you want to combine the changes from two parallel sets of changes, and not unless you explicitly ask for it.
As long as the changeset are identical, i.e. they have the same id hash. Mercurial considers them to be the same.
When you modify changesets with rebase or mq commands, the id hashs change and mercurial might place two very similar changesets into a repository.
Do you know any tool that support the followings:
eclipse integration (not mandatory)
merge tracking
interactive merge
merging with selecting changesets, but commit them one-by-one to preserve commit comments
So the flow I expect:
picking the source to merge to workspace
choosing revisions to merge
the program would do the merge for the first revision, would pop up conflict resolving if any, and if no conflict it would commit with the original commit comment + merging info with appropiate svn properties
go to next revision.
Do you know such tool?
No, I doubt any tool does this exactly as you describe - why would they when you can a) replicate the functionality by merging 1 revision at a time anyway, b) prefer to make the commit a manual process so the operator can check the merged results. Having merges commit automatically is just slightly optimistic.
You could write such a tool with script - for each revision, merge, fetch original log comment, commit.
Note you don't need to worry about properties as they are merged automatically as part of the merge process.
I'm just getting started with Mercurial, and I've come across something which I don't understand.
I made changes to several files, and now I want to undo all the changes I made to one of them (i.e. go back to my last commit for one specific file).
As far as I can see, the command I want is revert.
In the page I linked to, there is the following statement:
This operation however does not change
the parent revision of the working
directory (or revisions in case of an
uncommitted merge). To undo an
uncomitted merge, you can use "hg
update -C -r." which will reset the
parents to the first parent.
I don't understand the difference between the two (hg revert vs. hg update -C -r). Can anyone enlighten me as to the difference? And in my case, do I really want the revert or the update to go get rid of the changes I made to the file?
The first difference is revert can work on a subset of the working copy while update works on the whole working copy. the other difference is in what happens when you want to go back to a version other than the last committed one.
if we have revisions (caps are committed, lower case are changes in the working copy, parent revision is C )
A-B-C-d
update -C -r B will give you
A-B-C
with your working copy set to B, any changes will result in branching from B (parent revision set to B)
A-B-C
\e
revert -r B will give you
A-B-C-b'
where b' is a set of changes which undoes everything in the intermediate committed changes, in this case it undoes all of C. any changes now just join the b' set (parent revision left unchanged at C)
I am getting this error when trying to merge TFS2008. There are no pending changes on either source or destination branches.
TF14083: The item {0} has a pending merge from the current merge operation, please resolve and check in the current merge and merge again to pick up this change.
There is a "Resolve Conflicts(x)" link at the top of the pending changes window that I missed.
Did you read this article?
One of the suggestions there is to try the operation in a new workspace.
Also, if you have renamed or deleted one or more branches/folders, there might be changes in your workspace you're not aware of. Is there anything (even outside the source and target) in your Pending Changes window?
Here's a work-around worked for me.
Short version: Merge all files that don't report TF14083 first and check in changes, then perform a remerge.
Long version:
We had no files in shelves or not checked in, but when trying to perform a merge from one branch to another I got the error message TF14083: The item '' has a pending merge from the current merge operation, please resolve and check in the current merge and merge again to pick up this change.
My workaround was to merge all other files except those reported with a TF14083 error. Check in that merge, then perform a new merge from and to the same branches as previously, and now TFS picked up the changes in those files reported with TF14083 in the previous merge operation and merged them with no warnings or errors.
Go figure!