I have made some changes, Feature A that is done shelved and sent for code review.
While Feature A is being reviewed, I want to start working on Feature B, at the same time, I wish to have the changes Feature A available when I'm working on Feature B.
Once Feature A is done being reviewed (it can be during the development of Feature B), I want to check-in Feature A and Feature B separately.
I thought of:
Finish Feature A > shelve (and preserve locally) > review.
Then start Feature B (with Feature A changes) > check-in Feature A from shelve > finish Feature B > shelve(will it detect changes of Feature A as part of the pending changes here?) > review > check-in Feature B changes.
So my workflow now is to shelve Feature B and remove the changes from local before checkin Feature A changes.
Once checkin, Feature B gets unshelved and life goes on.
Related
Using TFS, but the question seems appropriate for any version control system.
In the following scenario I created a local folder named dev\1\< project > next to the main folder for feature 1 development as a branch off of the main. I merged it back when feature 1 was completed.
When it comes time to work on feature 4, should I merge the main back to the feature 1 folder (branch) and use it for feature 4 work, or as the picture below portrays, should I delete the feature 1 folder and simply create another folder to branch with for feature 4? Or is it no real difference? Perhaps there are practical issues not immediately apparent?
Picture taken from Professional Team Foundation Server 2013, St. Jean et al
When using Feature Branching methodology I prefer to delete the "closed" branch, and take a new one.
I do this for three reasons:
I can name the branch to something that is relevant to the feature being worked on
Removes any potential merge conflicts (and therefore reduces risk of regressions)
It's entirely possible that multiple features will be worked on simultaneously and this should be done in separate branches to allow isolation.
Every time I've coded a new feature (about once a day), I create a shelve set containing my changes and request a code review of my team lead (of the changes in the shelve set). He's pretty busy and it takes him half a day to a day to do the review. Meanwhile, I've continued coding the next feature, on top of the changes that I asked him to review.
My problem is: How do I then check in the changes that he approved, but not the (unreviewed) changes that I made after I created the shelve set?
As MrHinsh says you need to park what your working on and progress the code review check in and then return to what you are doing.
If you are using the the TFS code review then you will be using VS Premium or above, you can therefore use the My work tab to handle this process for you. You can Suspend what you are working on, revert back to your reviewed code, and when that is completed you can then restart the work that you were on.
TFS will shelve your changes and work items for the Suspend, when you then restart the work all of the source and work items will be restored back to the IDE and the IDE will revert back to the state it was in when you paused.
Information on the My Work can be found http://msdn.microsoft.com/en-gb/library/hh543900.aspx
There are really two main options for this:
You can shelve your new changes and revert. Then retrieve the shelve for the review and checkin. Then retrieve the new work.
You can have a seperate workspace that you keep clean of new development for checking in the reviews. Switch to it, get latest, and retrieve the reviewed code. Then check in.
I'm in a company now that forces TFS upon us. I have used Git all my life, and I am struggling to find some features I am used to in TFS. For example, I'd like to make small commits locally and push them up later together. This way I can keep track of my changes and roll back if I ever need to. Is there a way to do this in TFS?
What you're looking for is called "shelvesets" within TFS.
This link explains how to create one:
MSDN on how to create a shelveset
To shelve folders and files from Solution Explorer
In Solution Explorer, right-click, and then click Shelve Pending Changes.
In the Shelve - Source Files dialog box, type the shelveset name (for example, shelvetest) in the Shelveset name box.
The Shelve - Source Files dialog box includes two options:
Preserve pending change locally
By default, this option is selected. When this option is selected, the changes you made to the files or folders in your local workspace are preserved.
Evaluate Policies and check-in notes before shelving
When this option is selected, all check-in policies are evaluated before the shelveset is created. For more information, see Set and Enforce Quality Gates.
In the Comment box, type Testing my shelveset, and then click Shelve.
The files and folders are copied to the version control server and are available for other team members to unshelve.
And this link provides some background about using shelvesets:
MSDN on reasons to use a shelveset
For a variety of reasons, sometimes you need to set aside some or all of your work in progress. Shelvesets are useful when you want to stop work for:
Interruption: You have pending changes that are not ready for check in, but you need to work on a different task.
Collaboration: You have pending changes that are not ready for check in but you need to share them with another team member.
Code Review: You want another team member to perform a code review of your pending changes.
Private Build: Before you check in your changes, you can use your automated build system to build and test your code.
Backup: You have work in progress that you cannot finish now so you want a backup copy that is stored on your server and available to other team members who might need to access it.
Handoff: You have work in progress that you want to hand off to another team member.
Our development process works like this: Every 2 weeks the team lead (me) goes in and reviews everyone's changesets to make sure they are up to the coding standards. I would like to use TFS 2012 to help automate this process.
There are 2 problems with this:
There is no way to submit an unsolicited code review. I can live without this if necessary, I guess
There is no way to associate a code review with more than one changeset. This is a deal-breaker
I read one article which said it's possible to link changesets to a work item after the fact and when I open the work item for the request review I do see the Links tab. However, when I click "New" or "Link to...", there is no option to link to a changeset. There is only an option to link to each work item type in the process.
Does anybody know how to do this? Are there any plans to add these features to TFS?
Here's a screenshot:
Unsolicited, no.
You can rightclick a changset in the history screen to request a review post checkin.
And there is a nasty workaround to get what you want to achieve. Check out all files you want to review and request a review. You can then undo your checkout, the shelveset and the review request will remain.
Alternatively you can just go to the source control tab and do a checkout-all on the rootfolder of your solution, request the review, undo your checkout and do the review.
As for linking changesets to a Work Item, this can be done post checkin. Open the work item, go to the links tab and click "Link to..." The dropdown there will have a "Changeset" option. But I don't think this link type is enabled for Code Review Requests, since these use a Shelveset and not a set of changesets as the source for the code to review.
I expect you could use the TFS API to generate a shelveset with all the changes from a specific developer in a given timerange, put these on a shelveset and request a review on that. But no existing feature to do that exists.
Or you might be able to edit the shelveset of associated to the review by creating a new one with the same name.
An alternative approach:
1) at the beginning of the two week cycle, initiate the code review process and note the work item number that is created. Simply request a review from yourself with no code changes at first.
2) Have all your developers associate their check ins for the next 2 weeks with that work item #
3) When you are ready to perform the review, simply open the work item and go through the changesets.
That should accomplish what you want.
Option #3
[I'm assuming here that the changesets that your are trying to associate to a single code review are consecutive, for example 20001:20010]
I "roll[ed] back to a specific changeset" (in my example above
20001). I check it in the changes. The code is now in its original
state.
Then, I "roll[ed] back to a specific changeset" (in my example above
20010) and check it in again. The code is now in its final state.
Finally, I request a review on the latest revision. This review
compares the latest two commits - the ones I created from the
rollback.
As a bonus you can compare specific changesets in the history page. You can use this compare to make sure that the commits above did in fact revert the code to revision 20001 and 20010.
On item #2, I have a standard work around that you might like to combine all changes from many changesets into one shelveset for review. I tried the checkout method mentioned above and ran into issues, partly because my review had 25 files or so and after checking them out, if I refreshed, TFS removed them from pending changes because it TFS's opinion there were no changes.
First, (assuming that your changes are already checked in, and in multiple changesets), have a workspace with the latest files on a disk path such as D:\Latest...
Create a new "local" workspace (called "Review"), map the same project to the slightly different path (say, D:\Review...") get all the files. Go to the history of that project and just before your earliest changeset, right-click and select "Get this version".
At this point, go to the history and rollback any changesets that someone else may have changed in the meantime, if any, that you don't want to be part of the review, unless someone changed a common file. Leave those.
Using beyond compare, compare "D:\Latest..." to "D:\Review...", copy your changes from Latest to Review. Go into the common files and copy only the lines that you want reviewed. When Beyond Compare writes out the changes, TFS will detect the change and put the file you save in your pending changes list for the "Review" workspace. (That's a feature of local workspaces.)
At this point, you just shelve your pending changes from the "Review" workspace, and request a review on that shelveset.
So, we have our main dev line, I create a branch, and developer b creates a branch. We both do some work. developer b finishes his work, merges back into the main dev line. I know his changes will affect me, and rather than deal with the conflicts later, I would like to update my branch, with the changes that are now in the main dev line, so I can deal with them in my branch, prior to merging back into main.
How do I do that?
From Visual Studio, open Source Control Explorer:
View | Team Explorer
Select your Team Project from Team Explorer, expand it, and double click Source Control
In the left-hand pane of Source Control Explorer, select your Team Project.
In the right-hand pane, find your mainline branch, right-click and select Merge...
In the Target branch drop-down, select your dev branch.
If you want a subset of all the changes in the mainline:
Choose the Selected changesets radio button, click Next.
Select the changesets that represent the merge from your other dev's branch into main, click Next.
Otherwise, keep All changes up to a specific version selected, click Next
The next step has you pick a Version type. The default, Latest Version is obviously straightforward and self-explanatory: you would be brining all changes since your branch was created from the mainline down into your branch. The other choices are straightforward, but a tutorial explanation of each option available here would take a fair amount of space.
Walk through the remaining steps of the wizard.
Click Finish.
If there are any errors or merge conflicts, you will be prompted to resolve them, similar to what you would see if checking your changes into source control when other changes had been made since last checkout.
After the merge is done, all the changes are in your local copy of the branch, but they are not yet committed to source control. Once you've completed all your builds and testing on your branch, you can check in the merge. From Visual Studio:
View | Other WIndows | Pending Changes
Make sure all the files related to this merge are checked, add comments describing the merge, and click Check In.
I recommend keeping merges (and any necessary merge conflict resolution, build breaks, test breaks) as their own changeset. That is, do not mix other feature work with merges. Granular changesets make it much easier to review source control history, and to identify a single change of interest. Keeping merge work in its own changeset helps work toward that goal.
There is command-line for merging as well, run tf merge /? from a Visual Studio Command Prompt.