I am attempting to understand how TFS 2008 (and 2010 if it's different) store and communicate details of a set of changes in a changeset.
Now when I commit to a Subversion hosted project, the client sends diffs to the server. So if I have added a file and changed a few lines in another it sends something like "Added file A.txt, put 2 lines "A" "B" into B.txt" . This means I can back out a revision as diffs are nicely reversible - "Delete file A.txt and take out two lines from B.txt". Pretty sure it is the same with git too.
I have a feeling that TFS does not store changesets in this way (based on rumour and the fact that I cannot easily roll back revisions etc.).
What I believe occurs is this:
If I changed files A, B and C within a changeset, what is actually stored in the changeset is a whole new copy of files A, B, C. Not just the diffs.
Am I correct in this assumption? As commercial software, I could well believe this information is not available but I thought I would ask as googling produced nothing!
As a corollary: Where are TFS changesets stored? I know that SQL server is used for some storage... changsets too?
We are currently using TFS 2008 but it would also be useful to know the answer for 2010 as I think there are plans to upgrade.
TFS stores all changeset data in a SQL Server database. It stores the code from the most recent changeset in its entirety. It then stores a diff to the previous version. One of the benefits of storing it all in SQL Server is that it gains the "all or none" saving capability that is provided by transactions.
As for WHERE it's stored, you can check out this blog entry http://blogs.msdn.com/b/bharry/archive/2009/04/19/team-foundation-server-2010-key-concepts.aspx
Related
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.
Currently, our DBAs require the TFS changeset number for any scripts/stored procedures/functions that need to get deployed. I have a folder in our TFS project with all of my stored procedures in it, and I'd like to run a single query that will list each object in that folder and the latest changeset. I'm using VS2010 Team Explorer with TFS Server 2008 (I believe), and would be happy to script it in PowerShell or some other tool, but don't know where to begin. Can someone provide me some direction?
TFS has a lot of extensibility points that make running a query like this possible. If it were me, I'd simply use the tf.exe command-line client. For example:
tf properties $/Path/To/Folder -recursive
This will show you the latest changeset for each of the files beneath the given folder (as well as other information.)
While the output from the command-line client is well-formed and easily parseable, you may still prefer a more programmatic way to do it. You can use the very powerful .NET API in order to query from the server. You'll want to call the VersionControlServer.GetItems method. For example:
ItemSet items = vcs.GetItems(#"$/Path/To/Folder", RecursionType.Full);
If you haven't yet, you should take a look at the TFS 2008 Power Tools, which include the TFS Power Shell Extensions. My powershell-fu is weak, but I think that the above in Power Shell works out to be something like:
$tfs = get-tfs http://yourserver:8080/tfs/YourCollection
$tfs.VCS.GetItems('$/Path/To/Folder', $tfs.RecursionType::Full)
On my TFS server, how can I see where the source code (which folder) of my team project collection is stored?
I can't find anything specifying a location in the Administration Console.
Is the source stored on the file system?
Edit: Stupid question - got confused between TFS and VSS. TFS stores the source and changesets in a SQL database while VSS stores the source on the file system.
I had a similar question and that is how I ran into this thread but I knew that TFS stored data in a sql database but I wanted to know what table(s) because I wanted to make sure my setup was working correctly with friendly names that I had set up. I did a little digging and the root changeset table is tbl_ChangeSet in your TFS database. From there you can extrapolate what you need. Hope that helps.
No, you will need to check out the code to be able to see it. TFS stores Changesets, not individual files.
I started work a lone developer last year and I found VSS is no longer a good option for source control so I decided to use TFS 2010 instead.
I have had to learn everything from a book - of which there are few.
I am currently creating a new build and in my workspaces I see a have 4. I want to delete one of them and rename another.
However I do not know what the consequences of doing this are. If I delete a workspace, will that remove the associated files under source control? How do I check which files these are? What happens if I change a status from active to cloaked?
As you can see, I am a beginner in all this.
Workspaces are only a mapping from SourceSontrol folders onto your local file system. Also workspace contains information about versions of the files you have locally, so when you hit 'Get Latest Version' only recent changes are sent from server to you, not the whole files. Information on what files are checked out is stored in workspace too, so if you have pending changes in the workspace and delete it then there'll be a bit of a challenge to check these changes in. Renaming of the workspace will not break anything as far as I know.
Article An introduction to TFS Workspaces may be interesting to you.
Like the others have said, the workspace only says what local files you have checked out, and the status, etc. Workspaces are pretty granulal (i.e. per user and per machine) so you could have mutliple workspaces with the same username in the same project. E.g. if you have a copy of Visual Studio at work and one at home, you could have different files checked out and you wouldn't run into any conflicts like you would have in VSS or something based on VSS Like like VSSConnect.
We've had a couple of people leave out project and have had to go in and remove their workspaces after the fact. This hasn't been a big deal in terms of any code losses but if you don't have access to the machine anymore you will have to use the TFS tools.
Try TFS Sidekicks, it provides a nice GUI to manage all the nitty-gritty back-end stuff in TFS
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