TFS Guide for Subversion Users
Moving from one source control system to another is much like moving to a new town. You spend time finding where to get the same services in the new town, discovers what’s different, what’s new, and what is not available. In this blog post I’ll take a similar approach to explore what it is like to move from Subversion town to TFS town. I’ll use SVN terminology where it makes sense so you can quickly find TFS equivalent terms.
The TFS way to do a given Subversion Task
Importing Code
Subversion has an import command to add files and folders to an SVN repository. Once a folder structure is created, files and folders can be added using svn add. TFS does not have a separate import and add operation – instead it is all done with the tf add command. TFS does require a workspace (think working copy directory mapping) to be defined to map local folders to server folders. In Visual Studio the workspace is created automatically for you if you drag and drop files onto Source Control Explorer or if you add an existing solution to Source Control. To do this from the command line in TFS you do the following:
- cd into the top level folder you want to add
- Create a workspace - tf workspace /new
- Select the server path you want to add the folder to in the dialog
- Press OK
- Pend the add of the folder and it’s contents recursively by performing the following command. tf add .\ /r
- tf checkin
SVN Checkout and TFS Checkout are NOT the Same
One area of confusion for users moving from SVN is the term checkout. SVN checkout is the way to pull files and folders from the SVN repository to create a working copy locally. You typically only do this once and when you want later revisions you run svn update. The TFS equivalent of SVN checkout is creating a workspace mapping and performing a tf get which will copy the files from the server into the local files you defined in the workspace.
A TFS checkout is completely different than the SVN checkout command. TFS checkout is the way the user tells TFS they plan to make a change to a file. TFS checkout changes the file’s attributes from read-only to writable.
SVN Update
The update command is used to get the latest or a specific revision from the SVN repository to the working copy. The TFS get command accomplishes the same thing. However, there are a few key differences on behavior.
- SVN will look for missing files and place them in the working copy. TFS does not do this.
- SVN pulls down an extra copy of the file and places it in the .svn directory. TFS does not pull down an extra copy which means the space on disk that a TFS workspace takes is at least 1/2 the space that SVN uses.
- SVN pulls down files as writable while TFS pulls down files that are not checked out as read-only
SVN Commit
SVN commit (aka ci) is the equivalent of tfs checkin. Where they differ is
- tfs checkin has many additional features (see New Things you can do in TFS section below)
- After the checkin tfs makes the file read only while svn leaves the file writable
SVN Snapshots
SVN users create snapshots of changes using the copy command and tags (see here). TFS has a single command called shelve that copies changes to the server with a specified name. Shelved changes are a called shelveset. Shelvesets are a bit cleaner than SVN snapshots in that they do not pollute the folder structure of the repository.
Mapping SVN Commands to TFS Commands
SVN Command |
TFS |
Comments |
add |
add |
Svn has two types of add. Svn add adds files directories in an existing working copy. Svn import is used for the initial add to SVN. TFS has one add that covers both scenarios. |
blame (praise, annotate, ann) |
annotate |
tfs annotate provides a graphical display of who changed which lines. |
cat |
view |
|
changelist (cl) |
N/A |
TFS does not have an exact equivalent of changelist which is used to divide up changes into named groups. The named groups are known and stored on the local machine. TFS does have a concept called shelvesets. Shelvesets are named group of pending changes that known and stored on the server. Shelvesets are used to backup changes or to share changes with others that are not ready to check-in. |
checkout (co) |
Workspace mappings + get |
The svn checkout command is how you make an svn workspace and get the files\folders in SVN |
cleanup |
N/A |
It is good TFS does not have an equivalent for this. This command cleans up unfinished operations and locks from escaped commands or crashes |
commit (ci) |
checkin |
|
copy (cp) |
branch and label undelete shelve |
A branch and a label in SVN are effectively the same thing. By convention you run svn copy and copy a folder to the tags folder for labels and branches folder for branches
The SVN copy command combined with using tags is also the way you can share changes with others (see here). TFS has a cleaner way to do this using with the shelve command that does not create new folders in your repository. |
delete (del, remove, rm) |
delete |
Pends a delete much like TFS does. |
diff (di) |
status + diff |
Svn looks for changed files and diffs them in the workspace or per filespec Does not require network access |
export |
N/A |
Downloads files at given svn path but does not create an svn workspace for it |
help (?, h) |
help | |
import |
add |
Used for initial add to SVN. This is a poor experience because it does not support adding in place. In other words, you need to perform a “svn checkout” after the files are imported. TFS provides a much better experience here. |
info |
properties |
E:\my-svn-project\SCM\SourceControl\HatGui>svn info explorerscc.cs Path: ExplorerScc.cs Name: ExplorerScc.cs URL: file:///svn_repos/trunk/SCM/SourceControl/HatGui/ExplorerScc.cs Repository Root: file:///svn_repos Repository UUID: 1b4c991f-ee77-3e46-9549-95dc092285a7 Revision: 1 Node Kind: file Schedule: normal Last Changed Author: edhintz Last Changed Rev: 1 Last Changed Date: 2010-04-14 09:33:14 -0400 (Wed, 14 Apr 2010) Text Last Updated: 2010-04-14 11:28:12 -0400 (Wed, 14 Apr 2010) Checksum: b27f6cc3b266755f3f5e5aa09f69c057 |
list (ls) |
dir + |
Shows ls type output (size, date, last person to checkin) |
lock |
lock |
Svn locks can have a comment that others can see You can force steal the lock from this command These are checkin locks since svn does not have checkout\pend change |
log |
history |
|
merge |
merge |
|
| merge (reverse to rollback a change already commited) | rollback | |
mergeinfo |
branches + merge /preview |
|
mkdir |
add |
|
move (mv, rename, ren) |
rename |
In svn this is the same as a copy (branch) and delete |
propdel (pdel, pd) |
N/A |
Remove a property from a file TFS has nothing from command line. Can do from TFS SDK. |
propedit (pedit, pe) |
N/A |
Properties are versioned TFS has nothing from command line. Can do from TFS SDK. |
propget (pget, pg) |
N/A |
TFS has nothing from command line. Can do from TFS SDK. |
proplist (plist, pl) |
N/A |
TFS has nothing from command line. Can do from TFS SDK. |
propset (pset, ps) |
N/A |
TFS has nothing from command line. Can do from TFS SDK. |
resolve |
resolve |
|
resolved |
resolve |
Deprecated – added option to svn resolve to accept workspace |
revert |
undo |
SVN, does not require access to the SVN server to perform an undo.
TFS requires access to the TFS server. |
status (stat, st) |
status |
|
switch (sw) |
Tf get /remap |
Updates the local working copy to a different URL (branch) Equivalent to changing workspace mappings and doing a get |
unlock |
lock /unlock |
|
update (up) |
get |
|
Svnadmin dump |
N/A |
Writes contents\history of repository to a file |
Svnadmin load |
N/A |
Loads contents of a repository dump into a repository |
N/A |
destroy |
No way to destroy content in SVN. |
New Things You Can Do in TFS
There are many new things you can do in TFS (and we keep adding more :-) that you cannot do in SVN. A few of these are highlighted below.
Advanced Check-in Features
TFS checkin has many capabilities not found in svn commit. For example, you can associate or resolve a TFS Work Item (e.g. bug) with the check-in which creates a link between the changeset and the work item. You can also enforce rules at check-in time by creating check-in policies that require a comment or require that the developer ran unit tests before checking in. You can also configure well formed comments with required fields via the TFS check-in note feature.
Visualizing Changes
Nothing communicates like a picture and TFS communicates where a change is or where it came from visually with Branch Visualization. The Ed Square blog cover it here.
Destroy
TFS allows users with the proper permission to remove content permanently from the repository. This is handy to reclaim space when someone accidently adds that 6 GB media file. It is also essential if you need to remove code for intellectual property reasons.
Enjoy TFS
Although SVN and TFS have many features in common, they differ in places with their respective approach and have their own unique features. With a little learning and the right map (see above) the move from SVN to TFS can be painless and productive.