Is there a way in TFS to edit files and then (maybe) merge them later without having to do a checkout? Basically edit then only touch source control when I decide to update to the server, not in advance.
Or has 5 years of Mercurial and Git just led to me getting confused about how TFS works and what I want is not possible and doesn't matter because "checkout" is not exclusive. (most likely option? :-) )
(I have been here but that does not solve my issue)
There are ways to cheat that, but there's no good reason to do so. When you check out code from TFS, you're getting a local copy to work with. When you check it back in, it creates a changeset, which is an atomic commit of your changes to the source code repository. If you don't want to check it in, and go off and do something else, you can create a shelveset, which can be named and unshelved whenever you're ready.
Similarly, if you use Gated check-ins, that process creates a shelveset automatically and sends that for a validation build. If it fails, you just make changes to your shelveset and try again. If it succeeds, it checks a changeset into the source repository. It helps prevent checking in breaking changes.
Related
I work in many ASP.NET projects at once in VS 2019; I use TFS (without git), with a local workspace. As a way to make sure I have a "shelveset as a backup" in case I could lose my local work (hd fault, robbery, sticky fingers, lazy mind...), I am thinking of following these steps:
At the end of the day, I create a shelveset named with my username, preserving local changes.
The next morning, I continue working ignoring my first shelveset; Again, at the end of the day, I create a SECOND shelveset with my username+"2". When I'm sure it has been created without errors, I proceed to delete the first shelveset.
And the next morning I do the same, and so on...
What do you think guys, is it a good approach to make sure I will not lose any local changes in case of disaster?
Shelving is a simple way of storing your changed files. Your process is a bit convoluted. I'd simply run:
tf vc shelve /replace "daily backup" /noprompt /recursive
The command happens transactionally, so when it succeeds is replaced the old shelveset. If it fails, your previous changes will remain in tact.
An even better approach would be to craft smaller changes and to check in more often. That way your changes aren't just store on the server, but also integrated with your peers.
Visual Studio also has a built-in UI to suspend your changes. Open the My Work pael in Team Explorer and hit the Suspend work option. It will create a shelveset in the background.
The next day, simply Resume work:
A while ago, I accidentally checked in some unfinished unittest files I had changed and added in solution A together with some files that contained an actual bugfix for project B.
For some unknown reason I never noticed the checkin was going to include files from another solution so the checkin was done, after which other team members added more checkins to both solutions.
My question now is two-fold;
How can I undo the part of the checkin that hit solution A without affecting B at all
Is there a way to prevent mistakes like this from ever being possible to happen within Visual Studio (Enterprise 2015), make it impossible to checkin files not part of the currently opened solution somehow?
I think the easiest solution would be to use the ROLLBACK command, if you have installed the TFS power tools (TFPT) you should be able to do it within visual studio.
In your current branch, get the latest version from server then view history and find your changeset. Then right click and select "Rollback entire change set".
This will rollback the changes in your local workspace and checkout the file. (If there are conflicting changes you will have to resolve conflicts.)
Now when you are ready to check-in, exclude/undo the files which you don't want to rollback.
Commit/checkin the files which you want to rollback.
I haven't seen a better way of doing this, and think that this is much better than individually rolling back each file in the change set.
Now to answer your second question: check this ANSWER which I wrote a while back. I am copying it here for convenience.
As far as I tested, this default setting is controlled by the following registry entry. If the value of this registry entry is set as 1, then it should change the default behavior to filter by "Solution Changes".
"HKCU\Software\Microsoft\VisualStudio\12.0\TeamFoundation\SourceControl"
Name: FilterPendingChanges
REG_DWORD
Value: 1 = Show Solution Changes
Value: 0 = Show All
Do you really need a Branch to CheckIn / CheckOut Code in TFS i.e, just add files to a folder ?
What would be advantage to Branch in that case ?
You do not need a branch to check in and check out.
Branches however provide you with the ability to make changes to more thank one version of your code at once. Lets say that you have one folder at $/ProjectA/MyAwesomeApplication/Master. You can happily work away, checking in and releasing. At some point you find a bug in production that needs fixed immediately. However MASTER is well beyond what was last released and you don't want to deploy those changes yet.
You know which build is deployed and thus which changeset. You can branch MASTER at that changeset (the past) and create $/ProjectA/MyApplication/QuickFix. There you can fix that bug and ship, then merge back into MASTER and delete that branch.
Now obviously this is expensive and time consuming. A better way would to move forward and just ship what is in MASTER. If you have feature flags and good testing them you should be able to do that. There are however always those exceptions to that rule, and that's where branching comes in.
If you are using Git in TFS rather than TFVC the story is different.
I rolled back a changeset. Now I need to check out the changeset that was rolled back with 'actualized' pending changes. So like everything is before the commit of the changes.
When I get specific version with files override I see nothing in pending changes window.
How can I get the state I need? Is it possible?
After doing the "Get Specific version" you need to check out every file in the changeset manually (right-click, check-out). Be sure that you have the "Get latest on checkout" turned off.
After that perform a get latest, which will prompt you to merge. This is going to be a more tricky merge, since Visual Studio will assume that the newer version is what you want. When you're satisfied, check in the code.
Alternatively start with the same steps as the first solution, but instead of immediately doing a get-latest, you can create a shelfset after you've checked out each file and then perform a get latest. When you're on the target version, unshelf your changes, resolve any conflicts and check them back in.
Another trick you could apply is to find the changeset number that contains the rolled back changes. Since this checkin is a compensating checkin, you might also be able to re-do the changes by rolling back that compensating changeset. I tried this in a local workspace and it works. Again you might need to go through a merge and it's hard to tell exactly which changes to pick.
My best advice on this is: try not to get into this situation :).
Here's the part I get: When you shelve in TFS, it makes a server copy of the changes so they are not lost, but does not check them into the source code trunk/branch you are working on.
Question: Under what circumstances would you use the "unshelve" feature? Does it mean it will remove the shelveset from the TFS server? Can you do a get from a shelveset? Or is it really just a diff description between the shelveset and the "real" source code?
Unshelving is how you restore the shelveset to your machine so you can keep working on it. It doesn't change the shelveset on the server (to do that you need to shelve things again and use the same shelveset name).
One example for how I use it is to move changes between machines while I'm working on them. I'll shelve it on my desktop machine, then unshelve it on the laptop and then continue working on the laptop.
You can also use it to share changes with someone (for code reviews or other reasons). You shelve your changes, then the other person can go and unshelve it to see what you've done.
Unshelving doesn't actually change the shelveset or anything else on the server. It's just a get operation.
Herms is spot on. Read his answer.
One important caveat: if you've done a Get since the shelveset was created, Unshelve will only rollback the local version of files contained in the shelveset. Thus, it's quite likely you'll have an inconsistent workspace.
A good practice is to always re-run Get after you Unshelve. This ensures you don't waste time on phantom build errors that are actually just side effects of being in a half-new/half-old state. It will also require you to resolve any conflicts between the shelveset contents and the latest server revisions proactively, instead of only discovering them # Checkin time.
I use shelve to back up code-in-progress, just on the off chance my hard drive crashes or whatnot. I don't even have to worry about the code building, never mind working, since the work won't be seen by any other developers on my team (unless they go looking for it).
Unshelve pends the changes back in your workspace. Removing the shelveset from the server is a Delete.
Following on to what Richard Berg said, the power tools' version of unshelve actually includes a get and resolve.