Is there a way to see the date and time when a file was locked in TFS?
Just to be clear, I am not talking about check-ins. Only locked/check outs.
In TFS, Locks appear as a "pending change" for the person who locked the item. As long as the lock is in effect, it will appear as a pending change. When a commit is made of that pending change, the lock is released.
While the lock is in effect, the locked branch is effectively read-only, since (to simplify) the locker is the only user who can make commits. The act of committing is what releases any locks on the branch.
So the lock operation is first occurs at local side and will not be recorded by TFS. You could only get who locked the branch and check the branch status is locked or not at the moment. There is no way to query when a file/branch was locked in TFS. You could also take a look this similar question: when a file was locked in TFS
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
Person A does a merge
Person A spends some time QAing the merged code
Person B tries to checkin a change on one of the merged branches, and needs to go through the "there is a pending merge" dialog
Why is it that this happens, even when Person A has not yet replicated their merge to the server?
More specifically, what information is sent to the server implicitly on merge, and why? It seems odd from a user perspective that this is separate from replication, especially as it affects other users and forces them to merge from something that they do not yet have access to.
If Person A performs a merge and spends some time QAing, without checking the result in, it will not affect in any way to Person B. Impossible.
If Person A performs the merge and then he checks the changes in, Person B might face a merge operation if his changes are basing from a previous changeset and they are in conflict with the changes done at the merged changeset. If Person B changes are not in conflict with the ones merged then Person B can just update-merge, Plastic will let you do it: Update-Merge Dialog
Then you mentioned the "there is a pending merge" dialog, this dialog will only will be displayed when you start a merge operation, you don't finish it and finally you try to check-in the partial operation result. Once you face this scenario you should repeat the merge in order to continue with the unmerged candidates and finish the operation, then Plastic will let you check the merge in.
Finally, answering your question:
What is sent to PlasticSCM server in-between merge and replicate that
affects other users, and why?
I'm afraid nothing. If you start a merge at the central repository or the distributed repository it won't affect third party users working with replicated repositories, they are completely independent until you push the merged changeset to external repositories.
I'm unclear how the workflow/life cycle of a product backlog item should work - particularly when it comes to who should update the state and when that should happen.
Previously, we used TFS only at the task level, so anything that had to happen, the programmers would submit their code for a task, mark it as "DONE", then as a tester I would either find it was done correctly and mark it as "COMPLETE", or find some error or incomplete implementation and return the status to "TO DO".
Now we've set up an actual structure of Features, PBIs and Bugs, and tasks underneath but I'm still unclear on a few things.
For example:
Project Manager approves PBI and changes the state from NEW to APPROVED. It gets assigned to a sprint and the programmers mark it as COMMITTED, then write a number of tasks underneath. When they finish their tasks, they mark them as DONE.
How should I (the tester) know I can start testing that PBI? Are the programmers supposed to mark the PBI as DONE? And then I test it and if it doesn't pass, I turn it back to COMMITTED? If it passes, do I just leave it as DONE? (I find it confusing how there is a DONE for tasks and bugs that is different from DONE for PBIs).
Or do I look at the task level and see that all the tasks marked as DONE, and change them to CLOSED if they pass my testing or back to TO DO if they don't pass. I then only change the PBI to DONE once all the task testing has passed and all the tasks are marked as CLOSED? (one issue I have is sometimes the task is so programming-specific that I wouldn't know how to verify to change it from DONE to CLOSED).
Technically a "Project Manager" should not be involved in the process at all.
The PBI, as with everything on the backlog, is owned by the Product Owner. The Product Owner is accountable and responsable for the contents, and everyone else's understanding of said contents, of the backlog. However the Product Owner may not physically do anything and can delegate to the team.
So... The Product Owner, and the Development Team, should be the only ones changing states or editing Backlog Items. (caveats exist at scale).
Specifics:
As the Development Team is responsible and accountable for getting things to Done then they get to mark it as done when the whole team agrees that they have met the DOD.
Anyone can add something to the bottom of the backlog, but only the Scrum Team can change it and move it around.
The Product Owner approves the work, bit any member of the Scrum Team can proxy that approval and change the state.
There should not ever be a state after Done.
The whole team (analysts, coders, testers, operations) all work on a PBI in the Committed state. The work item stays committed until it is Done, or abandoned.
Note: You can find out more by reading the Scrum Guide: http://www.scrumguides.org/
We recently finished our first couple of sprints and some questions were raised to which we don't quite know the answer.
Both questions are related to: what should we do with backlog items, tasks and bugs which are not completed when the sprint ends? And how will a certain action influence a burndown or velocity chart?
If we have a 20 day sprint, my guess was that we should start on day 1, stop on day 20, leave one day for the next sprint meeting (day 21) and start the next sprint on day 22.
Let's say we have a PBI which has 3 tasks. One task is Done, one is In Progress and one was put back to To Do. The PBI has an effort of 6. If we move items in or out of the sprint during the sprint this has an influence on the Sprint Burndown and the Velocity chart. But once the sprint ended, and we move these items, does it still affect the charts? Or how should we handle such items? Should we close the PBI (set it to Done, even though it's not) or just move it and leave the tasks that were done in the previous sprint? Should we set all tasks to Done, even though some aren't? Each task has been worked on, so hours were used. We need to keep track of those, or at least, the velocity chart should still be OK.
A similar question rose for a bug. We added a Testing state, so instead of setting the state to Done, the developer sets it to Testing, so the test team knows which PBI's or bugs to test, and sets it to Done once it's completed. If a bug arises from a PBI, we close the PBI and open a bug for it. But if it's a bug, and it's not fixed, they reopen it. Either by setting it to Approved or Committed, but what happens with the efforts that were assigned to it? If the bug is not fixed when the sprint ended, should we set it to Done and open a new one, or just move it to the next sprint?
Scrum has been slightly revised and clarified over time; the latest version is more or less specified in The Scrum Guide (2011)
The Sprint Planning Meeting is part of the Sprint and it typically performed on the first day of the sprint (Day 1). Day 20 Will contain Sprint Review and Retrospective. Day 21 is actually Day 1 of the subsequent Sprint.
Regarding your question about the unfinished Product Backlog Item (PBI): Your goal is to establish a velocity for your team over time. CONSISTENCY is key to this. So most importantly, you should establish a way of doing it the same every Sprint. I see teams handle this is different ways; You need to determine if you actually delivered the Sprint Backlog Item based on what got done. If the value wasn't delivered, then you can leave it as not done and optionally update the final work on the tasks. You can also put a note in the history and/or description of the Sprint Backlog item about what was accompished and the acceptance criteria achieved. If the value of the item was delivered to some degree then you might make a similar note and count the item. You need not be exact about the points covered in the Sprint since they will average out over time, so you just need to use your judgement. Whatever is not done can be made a Product Backlog Item and prioritized accordingly. Your Product Owner may decide to put it lower on the Product backlog depending on the value of what was not finished in it. When the PBI representing the unfinished work, you will create a new set of tasks for it (you might copy the ones that were not completed from the Sprint in which they were not completed to save time). What is also important here is to discuss how things went and how you can handle this moving forward during your Sprint Review and Sprint Retrospective so your team can adjust accordingly.
Regarding the Bug, you might consider handling it similarly to the PBI for planning and prioritizing and Done / not done; your team needs a definition of done; if this includes testing, you should consider it Done only after testing. If it is not done then again you should handle that in a consistent way. Out of the box, the Scrum 1.0 version of the Bug work item has a state named Committed that indicates that the Bug is ready for testing, so you shouldn't need that testing state. Once it passes testing, it goes from Committed to the Done state. You can find the Process Guidance for the Scrum 1.0 template on the Microsoft site. It is more or less the instructions for how to work with the template.
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 :))