I got the 'resolve' dialog in TFS, and it looks like I clicked too fast on the wrong button (because they're too close together) and blew away a week's worth of work when TFS discarded my local changes. Is there an undo operation somewhere?
No, sorry. There have been many proposals over the years to move undone changes (and deleted files, etc) to the Recycle Bin instead of blowing them away, but the feature always seems to land on the cutting block. I'll see if there's an open request # Connect where we can add our votes.
PS: shelve early, shelve often!
No, there is not. If you have overwritten your local files, changes are lost.
Sorry (and hopefully, I'll be faster when rewriting your code :))
Related
We have a feature (that contained some DB migrations and 50+ changed files) that was merged into master a few commits ago. The powers that be now want that whole feature removed.
There have been no new migrations since this feature was added though there have been some new commits that we want to keep.
What's the best way to unwind this quickly, assuming small team and OK to force push to origin? Is it possible (read: recommended?) to:
rollback the migrations to the point right before this feature (PR) was merged
revert the git commits back to the same point
replay the more recent commits (by hash?) we want to keep (unrelated to the unwanted feature) back on the codebase
This will wreak havoc with other developers but we're a very small team at the moment and working together on this.
Or maybe there is a better way?
I realize rollbacks & reverts are covered in other topics here, and I've read many of them, but our situation is somewhat different as we want to rollback, revert and then replay certain commits and then bring origin up to date so it appears as though that bad feature never happened (or if easier, a merge commit reverting that feature PR would be acceptable).
Thanks for any help!
I'd suggest to add single migration that has code to revert all those 6 obsolete + 1 revert feature merge.
This way you'll
still have it in git history in case there'll be need to reapply, or reuse part of functionality
won't need to be too smart to safely reset git and DB to some state on each dev env + staging/production - which will avoid human mistakes
Is there a way to set up custom alerts on TFS? I already use the web interface to create alerts, but I need to create custom ones that are not based on work item fields only, but also on the current and past iterations. I know that Power Tools used to have an Alert Explorer in previous versions of Visual Studio, but I don't know if it would have supported what I am trying to do.
Essentially, this is what I need:
An alert that notifies users of unfinished work items assigned to them when the current iteration (sprint in my case) ends.
I know some of you might be concerned about TFS not knowing what the current sprint is, but I have used this workaround http://intellitect.com/transitioning-between-sprintsiterations-with-tfs/ so I don't believe it's an issue.
I know I could simply query for unfinished items and move them to another iteration (sprint) in Excel, but we are trying to get into the habit of getting everyone to finish their work on time, and if not, as quickly as possible, and the notifications would go a long way in helping with that.
Would there even be a way to do this via the TFS API or through the TeamFoundation PowerShell modules? I have searched extensively but I can't seem to find an answer to this question. Any help even with a work-around solution would be appreciated.
If you are trying to get people into the habit of updating their work items then this will cause you more issue than it fixes. They are not doing it because they do not see the value.
However you could write a TfsJob that sends the emails. It would need to be Scheduled job that checks to see if there is outstanding work...
This should get you started: http://blogs.msdn.com/b/chrisid/archive/2010/02/15/introducing-the-tfs-background-job-agent-and-service.aspx
However what you have is a people problem that cant be solved by tooling.
what I like is getting a job thing, whether a SQL server one or a windows service, running, then manipulate workitems by myself.
Using TFS Cloud (myproject.visualstudio.com), there are no Estimated, Completed, Remaining fields to add time to a bug. Do we really have to create a TASK work item basically called 'fix - bugname' for every bug, just to log how long each took to fix?
I appreciate on larger bugs this makes sense, but some are spelling mistakes or other minor problems.
This then doubles the number of work items in lists for all?
any suggestions?
Well, having looked into this, the quick answer is yes.
The benefits of doing so are simple. A TASK is the 'smallest' thing you can do in TFS, and it is always assigned to one person.
Given this, by creating tasks to do the 'work', you can at least see who did the work and account for it (without looking at the history of an item).
You can also 'bounce around' the assigned to for the actual BUG, e.g. to get someone else to verify it, or leave it assigned to whoever 'owns' that bug, while fixing it can be assigned to others (the tasks).
If you are using Agile or CMMI template the bugs will not appear on the task board.
Ideally, you need to create tasks to represent the work that you or team members are doing. For instance you need to create development task for fixing the issues and a QA task for testing.
Also you should keep an eye on the statuses of the bug in parallel to the task. i.e. if the developer is working on the fix the bug should be assigned to the Developer and it should be Active and the development task also should be active as well.
Once the development work is completed the the developer can close the underlying task and Resolve the bug and assigned it to QA for testing. If everything goes well the test engineer will close the testing task and at the same time he/she should close the bug as well.
Technically yes. What we've decided to do (purely for simplicity and not to bog us down with even more user stories in TFS) is we create one user story per sprint and name it: "BUGS - SPRINT#". Under that we will have tasks that track the work/time spent on bugs.
We also name the tasks by category. For example, if there is a bug in the UI, we name it (example) UI - arrows not reappearing.
Not sure if this is the best way to do it, but it accomplishes effort tracking and keeps TFS clean.
I take it that you are using the "Microsoft Visual Studio Scrum" template. The fields in the work items vary based on the template you are using.
For bugs in the Scrum template, we usually cover the effort in the "Effort" field.
We are Using Visual Studio 2012.
This is the way we are handling this situation. We have created a user story “ Resolving, Re-testing bugs.” Every iteration developers who have to fix bugs create a ONE task for all bugs. The developer adds comments to each and every bug resolved, and update time accordingly.
QA person also adding a ONE task for the iteration for re-test bugs. QA person update his task accordingly for each and every bug.
All Developers and all QA personal create child tasks for the same user story.
I have a common Core Data app for iOS. Every time something is changed, I call save from the NSManagedContext, so all changes are moved to the database.
As far as I understand, I can only undo changes from the managed context, but not from database. Am I right?
What I want is commit all changes immediately to the database and be able to undo the las action. Is that possible?
The only option I see, is not committing the last change, that is, leave the last change in the NSManagedContext, so I can undo that change. But this idea has a problem, if the program crashes or user makes a backup (using iTunes or iCloud), then this last change will disappear. Do you agree with me? How can I have my data always committed in the database and at the same time have the possibility to undo the last change? As far as I understand, that's not possible using Core Data. I hope I'm wrong.
Well, I would like to know your opinions about this. Thanks.
The reason I'm asking is that I want to test something, that I expect will generate a number of commits, totalling a lot of data, and since it's only a test, I don't want to leave them permanently in the database.
Do I have to set up a temporary TFS server for this, or can I just delete the project afterwards and expects its disk space to be reclaimed?
Disk space will not be reclaimed by normal deletion. You always have the option to undelete something in TFS, so changes will never get lost. (It's kind of a good feature in a source control system).
Do remember that TFS stores files as diffs between commits, so the disk space usage might not be so large as you expect.
You can, however, use tf.exe destroy to permanently delete your changes. I think this will allow you to reclaim disk space (though I haven't tested personally). Please be cautious if using tf destroy.