I'm new to TFS and have just taken my first dive into the TFS world the last few days (could say that my knowledge on TFS till now, is limited to just reading blogs, MSDN and quick read through a couple of books). Currently I've been given a task to extend a repository browser control which was earlier done by another developer (the referred TFS SDK version is 2010). The main purpose of this control is to list all the contents under a given path. I have a few queries that I would like to get clarified, before I jump into this;
- Will I be able to use the 2010 SDK to connect to TFS 2010, 2012 and 2013 Servers without the need to switch to newer vesion of SDK based on the server version?
I would also like to have a few commands implemented in my control which would allow users to;
- Apply label to a file / folder
- Lock / Unlock files
- Create a sub-directory under a folder
- Drop files / folders
I would like to know, whether I could have these commands executed without a local workspace mapping (Something similar as in the case of TortoiseSvn Repo browser where one could lock/unlock or drop file / folders without a local working copy).
Thanks!
- It depends on which part of the API you're calling. Some stuff will be backwards compatible without a recompile. Some stuff will need to reference the newer versions of the TFS API binaries and some stuff will need to be re-written as certain objects and methods have been deprecated in new versions of TFS. It's to broad a question really.
EDIT: You want to spend some time getting to know the TFS API documentation: If you're mainly concerned with Version Control operations then you want to become friends with Microsoft.TeamFoundation.VersionControl.Client and Microsoft.TeamFoundation.VersionControl.Common Then come back when you have some more specific details about implimentation of your code.
- No, If you want to manipulate files from Source Control you need to have a workspace. In TFS 2012 and above there are 2 kinds of Workspace, Server workspaces track changes on the TFS server and you must explicitly check out files to modify them. Local Workspaces Behave more like SVN and track changes locally. TFS 2010 only supports Server Workspaces. In addition to this TFS 2013 allows you to host a Git repository within TFS, However you cannot mix and match between TFSVC and Git you need to decide which one you want when you create the Team Project. You could potentially use SVN Bridge which wraps the TFSVC so that it can be called with the Tortoise tools, however that would add a lot of complexity to your solution, probably easier just to get the API to create a workspace.
EDIT: Once again the API Calls are all there, I haven't done much work in this space but the Item.QueryItem Method in the Microsoft.TeamFoundation.VersionControl.Server namespace is a good place to start.