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.
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:
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.
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 commit (aka ci) is the equivalent of tfs checkin. Where they differ is
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.
SVN Command
TFS
Comments
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
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
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
Downloads files at given svn path but does not create an svn workspace for it
help (?, h)
import
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
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
mergeinfo
branches + merge /preview
mkdir
move (mv, rename, ren)
rename
In svn this is the same as a copy (branch) and delete
propdel (pdel, pd)
Remove a property from a file
TFS has nothing from command line. Can do from TFS SDK.
propedit (pedit, pe)
Properties are versioned
TFS has nothing from command line.
Can do from TFS SDK.
propget (pget, pg)
proplist (plist, pl)
propset (pset, ps)
resolve
resolved
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
Writes contents\history of repository to a file
Svnadmin load
Loads contents of a repository dump into a repository
destroy
No way to destroy content in SVN.
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.
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.
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.
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.
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.