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.
Related
I work both from the office and at home, using separate computers. Currently, to be able to continue coding from home, I need to check in all my code before leaving the office. Is there any way of making my workspace work completely online, so that I can continue my work from home without checking-in anything when I'm leaving the office?
I'm currently trying a trick; mapping my workspace on a shared folder (network drive) which I can also access from home via VPN too. But it's taking too long to even download the latest version of the project. Even if this works, I don't think it will be an efficient way because of network speed limitations.
Is there any solution for multiple computers, one user and one workspace?
Assuming that you are using TFVC rather than Git for source control in TFS, then you can shelve your changes rather than checking them in.
Got to the Pending changes area of Team Explorer and click on the shelve drop down.
You now have a couple of options. You must add a name then you can select
preserve pending change locally. This allows you to keep your
changes in the machine you're currently working on.
Evaluate policies and notes. This is only necessary of you have check in
policies set up and it can be ignored if you just want to store your
changes as they are not complete and applying policies at this time
might be inappropriate
Once you have done this then hit shelve. You changes are now stored on the server. When you get to your other machine go in to "Pending Changes" and select the Actions drop down and select "Find Shelevesets"
This will present a list of shelvesets committed by you. You can search for shelvesets by other users but in this case the most recent shelveset created by you should be at the top of the list.
Right click on the appropriate shelveset and select "unshelve". You should now be able to continue working where you left off.
I am using Visual Studio 2107.
Looking at the “Pending Changes” panel in Team Explorer, there are two list for “Included Changes” and “Excluded Changes”.
I can use the Filters option to display only files that match a certain pattern. However, I want to be able to hide files that match a certain pattern.
The reason is that I have a number of files regenerated during the development process; these files all have the same name in different projects. They clutter up the list when I am reviewing what to check-in.
Note that I don’t want to exclude these files from being checked-in; they will be checked-in to source control eventually. I just want to be able to review the Changes list without these files displayed until I want to see them.
It seems straightforward but I can’t seem to figure out how to do it. And I can’t seem to find the right phrasing for Google.
How do I hide files in Team Explorer Pending Changes View?
If you don’t want to exclude these files from being checked-in, I am afraid you could not hide files in Team Explorer Pending Changes View.
According to the document Develop code and manage pending changes:
Almost every change that you make to the files on your dev machine is
stored in your workspace as a pending change until you check it in.
If items that you don't need to check in appear regularly in the
Promote Candidate Changes dialog box, you can select one of them, open
its context menu, and choose Ignore this local item to ignore the
item. You can also choose Ignore by extension or Ignore by file name
to create a file that will cause Visual Studio to systematically
ignore this kind of file.
So, Pending changes will detect all your changed files unless you don't want to check them in.
So, to hide files in Team Explorer Pending Changes View, we need to use .tfignore file to ignored files to folders that are mapped in a local workspace, they do not appear in the Pending Changes page in Team Explorer. When you want to check them into source control, you can move them out from .tfignore file.
Hope this helps.
Hiding files from Pending Changes is not supported without fully ignoring them.
I'm housekeeping the TFS Server and have 40,000 shelvesets of which 6,500 are for the Build Service Accounts.
I assume i can simple remove these as i don't think the builds will refer to old shelvesets.
I exported all current shelvesets.
Can someone confirm if we can just delete all of these? Or will we run into trouble if we want to run an old build
We are running TFS 2017.2
I don’t see any reason to keep them. Since commits should be occurring therefore giving you code history and reproducible builds.
If you delete a shelve set you cannot retrieve it latter for any old builds.
Shelve sets are not the same as code commits
Reference the MSDN documentation which applies to TFS 2017 and shelve sets for use cases.
the purpose is not to be a version history of code changes or
associate code with builds.Thats what commits are used for.
Shelve sets are temporary. However, no rule stopping you from keeping forever. Unlikely any value would be gained from so many
though.
there is not a need to reproduce a build with a shelf set that is older then your code release cycle because commits our occurring making the shelve sets moot.
#NOTE: I do not know why you would have the build agent doing code shelve sets. I would look at your build definition and take out anything automatically creating shelve sets.
Its always advised to find the details of shelveset unless you know its old enough to delete. You must be a shelveset owner, or your Administer shelved changes permission must be set to Allow as explained here. Shelveset commands to delete/find/list/... are listed here
TFS Sidekicks tool provides a dedicated UI for a number of clean-up actions, including old shelvesets till TFS2015. Not sure about its working in 2017
Is it possible to view history and compare with shelvesets? We are investigating the possibility of using shelvesets instead of check-ins. From our initial investigation it seems we cannot view history like we do for check-ins.
We are using Visual Studio 2010/TFS 2010.
From http://msdn.microsoft.com/en-us/library/ms181403(v=vs.90).aspx
Section: The Difference Between Changesets and Shelvesets:
Unlike a changeset, a shelveset is a non-versioned entity. If you or another user unshelve the items of which a shelveset consists, edit several files, and reshelve the shelveset, Team Foundation does not create a new version of the items for future comparison and maintains no record of who revised the items, when, or in what manner. The original shelveset is completely replaced.
So, no, you can't review history. I am unsure on methods of comparing shelvesets. You should also read that entire section (The Difference Between Changesets and Shelvesets) as each item in it is a strong argument to not use shelvesets in the place of changesets.
I also cannot think of any reason why using shelvesets instead of changesets would be desirable, maybe you can list the reasons why you all were exploring this path. Just think about not being able to track changes, that alone should be a deal breaker (of course, shelvesets not even being versioned should just about do it)..
Like it says on the link posted by dugas, shelvesets are built more for...well, shelving things. For example, on the project I am working on right now, I did a shelveset for some refactoring changes I was in the middle of because something unrelated broke and I needed the code back to the original non error-filled version. I also use it for when I'm in the middle of attempting something and want to have a backup but I don't want to check in code just yet.
There's no versioning on shelvesets, but it is possible to compare code in a workspace, to the code in a shelveset, without pulling the shelveset files.
Pull the versions of files you want to compare the shelveset contents to, into a workspace
open the solution in that workspace
File >> Source Control >> Unshelve Pending Changes...
find the desired shelveset and bring up its details
On each file in the Shelveset Details window, you can right-click and select Compare >> With Workspace Version...
TFS will pull the shelveset file to a temporary location, show the diff, and then (?) clean up the temp file after you're done.
You'll be comparing the shelveset file contents, to the contents of the files on the local disk in this workspace. If changes were made to both files, the compare won't be able to tell and will indicate all those changes. However, you can compare the selveset version to its original (Compare >> With Unmodified Version..), to see all the changes that were made just to the shelveset file. You can also find out the changeset that was the base for the shelveset file (Properties..), and see what changes were added to the workspace version since that common base changeset.
There's no tree compare though, and this may require the TFS power tools to work.
P.S> I don't recomment trying to use shelvesets in place of checkins like this. If there's one thing I've learned over the years, it's not to fight Microsoft's designed-in workflows -- you do things their way, or you find a different tool. Microsoft doesn't intend you to use shelvesets this way (they want you to use changesets and a branch), and if you try, you'll constantly be fighting Microsoft's designed-in workflow.
You can use shelvesets for peer code-review before committing them to the repository ... and also for parking commits before going through a gated build process.
They are not suitable for anything other than "quick shelving" of work - use branching if you want to have multiple parallel work streams.
I'm a consultant whose client runs a TFS 2005 repository. I manage my own source code in TFS and deliver my releases to their TFS. My source code is around 20,000 files that I maintain.
My normal process:
Detach my solution from my TFS
Connect to their TFS
Checkout the entire project
Overwrite my project files with
theirs
Check everything back in
Click the add button and add any new
files that have been added
Check everything in
Open the solution file and bind it
to TFS
Check everything back in
The main problem I'm seeing with this approach is if I delete a file on my end, I don't have a way to reflect that change.
I'm also not interested in synchronizing tools because I don't want to synch every checkin, just the current state.
Is there a way I can do this better?
What about maintaining parallel .sln and .proj files with the different bindings? Do they change often?
I think you can maintain change history by using the TFPT ONLINE command from the Team Foundation Power Tools.
Open SLN_A
Make changes (VS auto-checks out against TFS_A)
Before checkin on TFS_A, run TFPT ONLINE against TFS_B. This should pick up adds, edits, deletes.
Checkin SLN_A on TFS_A.
Checkin SLN_B on TFS_B.
Only problem with this might be that the SLN_A checkin could screw up the SLN_B pending changes b/c the files will be returned to read-only. Not sure.
Why do you need to maintain a parallel TFS? Seems like you ought to be working directly against their TFS, either on a branch, via the Proxy, or both.
Have you looked at TimelyMigration? (No affiliation and I've never had need to use it)
TFS to TFS migration