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.
Related
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 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
So in a typical workflow of a developer, it goes something like this:
You sync your workspace to some changeset, do some work, shelve changes you've made.
My question is, internally, when you create a shelveset, does TFS keep track of which changeset the changes are based on? If so, is there a way to look this up?
My rudimentary understanding is that, yes, this changeset information must be somehow recorded because shelvesets are stored internally as delta's, as opposed to full copies of files and without a record of which changeset the delta is based on, a delta is basically useless.
That may be a typical workflow for your team, but I'd say that it's not a typical workflow in general.
Shelvesets are intended for short-term suspension of work in progress that's not quite ready to be committed to a dev branch, generally in the case of something exceptional occurring that requires immediately switching contexts (e.g. troubleshooting or fixing a bug).
Internally, TFS actually stores most files as reverse deltas. Why? Probably because the most frequently accessed state of a file is the current version, and having to "build" the current version by playing forward a series of changes to the originally file is going to be a lot more expensive. Basically, when you go to look at an old version of a file, it takes the current version of the file and "peels off" the intervening changes until it's back at the old version.
Your specific question is actually directly addressed:
Shelvesets also use the same mechanism for storing their content. However, with shelvesets, no deltafication happens. Each shelveset gets a new copy of its file(s). (except in the case of a merge). When a shelveset is checked-in, a shallow copy occurs and the committed version of a file uses the same content as the shelveset copy of the file referenced. Deltafication will be started on the previous version of the file(s).
So, long story short, shelvesets are not based on changesets.
I concur with Daniel's answer that the files of a Shelveset are copies of new files. However, I'm not sure when this was incorporated but currently in VS2017 the Changeset is actually stored. When looking at the Shelveset Details if you hover your curser over a file among the details displayed for the file is the "Version" it is based off of.
Example Image
I don't know how useful this will be for the typical user as I have found one of the best features of Shelvesets is the modularity and separation from the version control but it never hurts to have that context.
Cheers!
I'm trying to write a very lightweight "build" script which will basically just get a few files from TF (based on a Changeset number). Then I'll run those files in SQLCMD.
I'm using this:
tf.exe get c:\tfs\ /version:c2681 /force /recursive
However, this appears to get EVERYTHING, not just the files in changeset #2681. I'd like to be able to point it to the root of my tfs workspace, give it a changeset number, and have it just update those few specific files. Also, it appears to be getting older versions (perhaps what was current when changeset #2681 was checked in)?
Is there a way to get just those specific files, WITHOUT needing to call them out specifically in the tf get itemspec?
EDIT: I actually had to add the /force option in order for it to do anything at all. Without force, it doesn't appear to even retrieve from the server a file I deleted locally, that's definitely in the changeset.
thanks,
Sylvia
Everything mentioned in Jason's and Richard's posts above is correct but I would like to add one thing that may help you. The TFS team ships a set of useful tools separate from VS known as the "Team Foundation Power Tools". One of the Power Tools is an additional command line utility known as tfpt.exe. tfpt.exe contains a "getcs" command which is equivalent to "get changeset" which seems to be exactly what you are looking for.
If you have VS 2010, then you can download the tools here. If you have an older version, a bing :) search should help you find the correct version of the tools. If you want to read more about the getcs command, check out Buck Hodges's post here.
The TFS server keeps track of what each workspace contains1. Any changes made locally with non-TFS client commands (whether tf.exe, Team Explorer or another client) will lead to differences between the TFS Server's view and what actually exist.
The force options on the various clients just gets everything removing such inconsistencies (effectively resetting both what is on the client and what the server thinks is there).
When you perform a get against a specified version (whether date, changeset or label) you get everything up to and including that point in time, whether on not specifically changed at that point. So getting
tf get /version:D2012-03-30
will get changes made on or before that date.
To get only the items included in a changeset you'll have to do some work yourself, using a command to get a listing of the content of a changeset and parse that to perform the right actions (a changeset can include more than just updates and adds of files2).
It seems to me that if you want to perform a build at each changeset affecting a particular TFS folder you would be better off looking at using TFS Build which is all about doing exactly that – avoid reinventing the wheel – and focus on the build part (other continuous build solutions are available).
1 This will change with TFS11 local workspaces.
2 Eg. handing the rename of a folder will take some non-trivial work.
The command will get all the sources for the given changeset. By default it will only get the files that it thinks are different between your workspace and the server. However, by using the /force option you are asking it to get everything regardless of the state it thinks your workspace is in (which is much slower but has the benefit of ensuring your workspace is fully in sync with the server).
So just removing /force will probably achieve what you want.
edit
As I said above, tfs will get all files that it thinks are different from the server. If you manually delete a file from your local workspace, TFS won't know that it is missing from your local version, so it won't think it needs to update the file. There are three solutions to this:
Use /force to make sure things are in sync, and put up with it being very slow.
Don't modify files in your workspace with anything other than TFS tools (tf.exe, Visual Studio, TFS power tool for the explorer shell). You shouldn't just delete files on your local hard drive - if they really need to be deleted, then delete them in source control.
Go offline in TFS before you make changes manually. Then when you go online, TFS will search for all the changes you have made and add them to your pending changes so that TFS is aware of them.
Yes this is one of the Doh! Damn! I shot myself in the foot. I don't have a lot of experience with TFS in large teams, but I'm facing this issue.
During a transition to new equipment, a developer forgot to check-in some code. Work proceeded on the new laptop for several weeks before noticing that the previous work was not checked in. Mutliple check-in have occured.
I have recovered the files from the old laptop, and have them on my current laptop. What is the best way to merge in these changes? Do I create a branch, merge in these changes, and then rejoin the branch?
Is there a "cookbook" out there that details what should happen when faced with various situations?
We are using TFS 2010.
Thanks in advance...
Creating a branch here is probably a little bit heavier-weight than what you need for this one-off situation. If it were me, I would do this:
Set up a workspace on your computer with the appropriate mappings.
Do a Get Specific Version to the version that the other computer was at. The best case scenario is if the user never deleted their workspace on the server. Then you can simply specify their workspace as the version and you'll get the files as they existed on the laptop. (You can specify this as Wworkspacename;owner name.) If the user deleted their workspace, you can get based on the changeset number they were at, or based on the date they were working at.
Copy the recovered files on top of the new TFS workspace.
Run tfpt online from the Team Foundation Server Power Tools. This will examine the local filesystem against the server and determine what changes were made. You may wish to examine the options, notably the /diff flags (which performs MD5s on the file instead of simply examining the readonly bit), and the /deletes and /adds flags, which detect deleted and add files, respectively.
Do a Get Latest on your workspace, resolve any conflicts, and check in.
You can follow this sequence to try out:
Make a merge-branch of your code version based on the time-stamp of where your restored laptop code has left the version control system.
Get your branched code to a location on disk.
Perform a check-out for edit of the entire workspace.
Copy the old restored code over the files in this workspace.
Perform a checkin of the local code into the branch.
Merge your latest code (main trunk) into the branch, merging changes, solving conflicts.
If all build and tests out correctly on the merge branch, merge that branch back into the main.
That should do the job.