I was wondering:
In TFS2008 What is the difference between "Undo Pending Changes" & "Unshelve Pending Changes" exactly?
Since I have upgraded to the new TFS2012 power tools I no longer can "Undo Pending Changes" on our old tfs2008 instance. But it still gives the option for "Unshelve Pending Changes".
VERY VERY different.
Undo means you have checked something out, and may have made a change, but instead of checking it in, you are going to throw it out; erase it; delete it - AKA do not push this button unless you really really mean it.
To unshelve pending changes you have to have previously shelved some changes. Shelving means that you are saving them for later, leaving a copy of them where they can be retrieved if needed. So unshelving means that you are getting that copy back in your work space.
If you can no longer undo pending changes, hopefully that just means that you don't have any changes pending.
Related
I'm looking to do something similiar in functionality as git cherry-pick. My situation is thus: I mistakenly promoted from from stream C to Stream B, realized it was an error and reverted the transaction, this succeeded. But unfortunately I now no longer have the code In stream C that I had before the promote. I've tried doing a send to workspace and merged the underlaps but this puts me in the same place I was in before, I no longer have my changes. if I keep the overlaps I get overlaps with almost all the files.
I'm really at wits end, I know if this was Git I would have reverted my bad commit, merged the reversion into my feature branch, then cherry-picked the original commit.
accurev has broken me, I'm ready to cry and need some help :,(
In the future, you could have done a demote (new feature in AccuRev 6.2.0) of your changes in streamB and put them back in streamC (very slick new feature IMO).
To resolve your situation, perform the following steps.
Hang a workspace off of streamC.
Update this workspace.
Right click on streamB -> Show History -> Select the promote transaction -> Right click -> Send to Workspace -> Choose workspace from step 1.
Depending on your version of AccuRev, click on the "Default Group" filter or "Outgoing" filter.
Select all of the files included from the send to operation -> Right click -> Merge. You will not want to automatically keep the merge, but need to manually select the version of the file in your workspace (lower right hand pane). This contains the changes from your initial promote. After you have done this, keep and exit.
Now promote your changes into streamC.
The demote feature basically does all these steps for you in one operation BTW.
I have tried diligently to find bazaar user groups. I tried pressing the community tab on their website. There seem to be only mailing lists, but where does one start? The title says it all. I have tried revert, but since it was uncommitted, it did not work. The names of the files in question show up on 'bzr status' under 'missing'. the other files show up under 'added'. I am a bazaar rank beginner, and though I knew about commit, just forgot to do it after adding. Are the files well and truly lost, or is there a way to get them back? In the list you presented before answering, the only one which comes close to my situation is: "How can I un-delete an uncommitted", but unfortunately is for svn, not bazaar. This is my last shred of hope. I have held off doing commit now because I am afraid of losing the little which remains, since Bazaar says the are missing.
If bzr status says missing rather than removed, then the files were deleted from disk after they had been added but before a commit happened, I'm afraid.
Under these circumstances, bzr revert cannot help you; it will restore the working directory (or part of it) to the state of a specific revision. Without a commit, there is no revision to revert from, because the system has no record of your files.
If you have backups for your system, you may still be able to recover files from there.
I have come across an issue that looks like TFS has permanently deleted a branch and all of its history and is not giving me the ability to interact with any of the changesets that were in that branch. Here is what happened:
I created a new branch(A) off of an existing branch(B).
I used A for a few months.
I merged everything in A back to B.
I deleted A by right clicking on the branch in Source Control Explorer and clicking delete and checked in the change.
[At this point I didn't check to see if A could be undeleted, and didn't notice anything amiss]
2 weeks pass
Now I want to view the history of a file that was merged
I go to the visual studio settings and check the box that shows all deleted items
A is nowhere to be found
I check to see if some other branches that I had deleted in the past were visible, and they are still present.
I look in the change history of the parent directory and I can't even see the changeset from when I deleted A.
I have admin access to the TFS database, but don't understand the schema well enough to search for all "delete" changesets.
I've tried to use the API in Microsoft.TeamFoundation.Client to get more information, but it isn't providing any more records that the TFS history window did
Update
I just ran a a tf destroy command on a test branch to see what the symptoms are, and the symptoms are consistent with what I'm experiencing. I suspect that this branch was destroyed, now my goal is to find out if destroy leaves behind any information about who or when
Further investigation reveals that a team member on a different project had run a cleanup script during the two week period that had invoked the destroy command, accidentally destroying some of our deleted branches. The advice in How to find out who ran the TFS Destroy Command? revealed who it was, and how it had happened.
Why isn't it standard behavior for Accurev to automatically run an "Update" upon opening the program? "Update" updates a user's local sandbox with the latest files from the building/promoted area.
It seems like expected functionality that the most recent files should be synchronized first.
I'm not claiming that it should always update, but curious as to why an auto-Update wouldn't be correct.
Auto-updating could produce some very unwanted results.
Take this scenario: you're in the middle of a development task, but you've made a mistake and need to revert a file that you just modified. So you open AccuRev, but before you have a chance to "revert to most recent version", you are bombarded with 100 files that have been changed upstream including the one you want to revert. You are now forced into the position of resolving all the merge conflicts before your solution will build, including the merge of your (possibly unstable) code in progress.
Requiring the user to manually update keeps a protective 'bubble' around the developer, allowing them to commit (keep) changes within their own workspace without bringing down code changes that could destabilise the work in their sandbox. When the developer gets to a point where his code is ready to share with others, that is the appropriate time to do an update and subsequently build/retest the merged codebase before promoting.
However there is one scenario that I do believe auto-updating could be useful: after a workspace is reparented. i.e. when a developer's workspace is moved from one part of the stream hierarchy to another. Every time we reparent we have to do a little dance:
Accept the confirmation dialog that reminds us (rather verbosely) that we need to update our workspace before we can promote any changes.
Double-click the workspace to view its files.
Wait for AccuRev to do a "Pending" search, to determine whether any file changes are waiting to be committed.
And finally, perform the Update.
Instead of just giving us a confirmation dialog, it would be nice if AccuRev could just ask us if we want to Update immediately.
I guess it depends on preference. I for one wouldn't like the auto-update feature.
Imagine you have a huge project and you don't want to build it every time you start Accurev. But you also can't debug because the source files and debugging info no longer correspond.
Hit the following situtation a couple of times today:
Myself and another dev both have bazaar local checkouts of a repository.
I make some changes.
The other dev makes and commits some changes.
I update.
The other dev realises their previous changes were broken and uncommits them.
I update.
Now the other dev's uncommitted changes appear as a pending merge in my local checkout, and I can't find a way to separate them from my changes and remove them from my 'local' tree.
Every time this has happened I've had to manually work out which changes are mine and which are not, save my changes, revert, and then re-apply my changes.
I've tried doing a "cherrypicking" reverse merge on my checkout between -r -1..-2, and between -r 0..-1, but neither helped. (0..-1 said "nothing to do", although I might not have done it properly. -1..-2 was the wrong set of changes and thus made things worse.)
How can I fix this situation when it happens (other than going over and smacking the other dev upside the head)?
It is recommended that you don't uncommit in branches that are published somehow, thus avoiding this issue.
Well once you have updated (step 4), the other guy's changes will be merged with yours permanently. Since your changes were uncommitted, they aren't stored anywhere. Therefore, once step 6 has happened, I don't really see a way of automatically separating out your changes from his.
So let's say you manually remove all of his changes so you're just left with yours. You still have this pending merge to deal with. You can fix that by typing
$ bzr revert --forget-merges
That will not change your working tree; it will only remove the pending merge from your "bzr st" so that when you commit it will not look like a merge. This should save you from having to save your changes, revert and re-apply.
To avoid this happening again, you could run bzr update only immediately before you commit. Once merged, to a bzr commit right away, and your changes are locked in. Now he won't be able to uncommit without first updating and seeing your changes, and now it's probably too late for him to do that. If he really wants to go ahead with his uncommit, he's the one that has to deal with the mess, not you.
One final thing you can do -- if you really don't want to deal with it and you don't care too much about having a nice version history. After step 6, just commit. Maybe explain in your log that the other dev uncommitted this change but too late.
This is where the pending merge comes in. If you commit, the uncommitted revision will go back into the repository, as a branch, just as if the other dev had send those changes to you in an email and you merged them. It will look like this:
------------------------------------------------------------
revno: 34 [merge]
committer: You
branch nick: trunk
timestamp: Fri 2010-11-26 15:57:27 +1100
message:
Made my changes to the file.
Note, other guy did some of these changes and uncommitted, but
I already merged.
------------------------------------------------------------
revno: 33.1.1
committer: Other Guy
branch nick: trunk
timestamp: Fri 2010-11-26 15:39:39 +1100
message:
Made some changes to the file.
------------------------------------------------------------
When he runs update again, he'll have his old changes thrown back at him, and probably get a conflict. He'll have to clean it up, then commit his fixes (whatever reason he had to uncommit in the first place). This is probably just as effective as a smack upside the head, and works over a network :)
It looks like bzr pull --overwrite :bound is what you're after.