good morning, people!
A co-worker has made some changes to the project and now it is necessary to do the same so that I do my part now. However, he can not give a check-in because another team member "pulls" the latest version, it will pick up that part that no case could not, only I could remove those changes and after I do as the changes, yes do the standard check in.
This refeel a my doubt, should be something simple. And neither is it done the same for this not TFS. It's possible?
Your title is talking about how to share shelve with other TFS Members. There is a concert called Shelvesets in TFS. Shelvesets are useful when you want to stop work for:
Collaboration: You have pending changes that are not ready for check
in but you need to share them with another team member.
Other peoples could share their pending changes(haven't checked in) to you through shelveset. You could unshelve his shelveset which restores shelved file revisions, check-in notes, comments, and work item associations to the current workspace.
If you don't want the shelveset mess up your local work in VS, please also take a look at my reply here: Undo TFS Unshelve
Related
I'm trying to rename a shelveset. The only way I can think of to do it is:
Unshelve it (uncheck Preserve shelveset on the server)
Gather all the changes into Included Changes (and exclude everything that wasn't part of that shelveset).
Re-shelve it with a different name
Is there an easier way?
(we are using TFS Version 15.117.26714.0)
What is the easiest way to rename a shelveset in TFS?
Personally think the method you think is the simplest or most direct.
Since TFS teams Suggested on their old user voice forum(Closed now):
Visual Studio Team (Product Team, Microsoft) responded · March 11,
2015 Thanks for the suggestion! We’re currently in the planning
process for enabling an iterative shelveset experience. We’ll update
this item when we have more details.
But so far, we do not have a very easiest way to rename a shelveset in TFS. And we do not have a "update shelveset" API in place:
Shelvesets
Do not have option to rename the name by the Shelve Command.
You could check this thread for some more details.
So, I agree with your idea is the easiest and most straightforward, and it is also the method I have used.
Recently, one of the junior developers made a check-in to a large MVC SOA C# application, to both the client and service side, which makes the project unbuildable. Their check-in added spurious dependencies as well as removed required files, with something like 900 files in the project affected.
In order to keep the project moving forward, I was instructed by management to simply obtain the project from the changeset prior to this check-in in TFS and and then apply all changesets after the bad check-in going forward, since we though a release would be urgently needed.
As the weeks have passed, however, this approach is getting untenable. Is there a way to do one of these two things in TFS?
Either
remove a changeset from TFS without removing the changesets that come after it?
or
Automatically get all of the changesets in TFS for a solution except for one specific changeset.
remove a changeset from TFS without removing the changesets that come after it?
According to the document Roll back changesets:
A changeset is a permanent part of the history of your
version-controlled items and cannot be undone or removed. However,
you can roll back the effects of one or more changesets.
So, we could not remove one specify changeset. Just like James said, we could roll back the bad changeset. But it will also remove the changesets that come after it. As workaround, you can check the Changeset details for that specify changeset. Then ask that the junior developers remove his code, then check in the delete changeset.
Automatically get all of the changesets in TFS for a solution except
for one specific changeset.
There is way to find and view a TFS changeset by comment text:
tf history $/ -r | ? { $_.comment -like '*findme*' }
Check the this thread for some more details.
But there is no such out of box method to exclude one specific changeset in the text, we need to write our scripts like, batch, powershell to except it from the text.
Hope this helps.
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.
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.
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.