1. Subversion
Dos and don'ts

2. Advantages of SVN over VSS
• Atomic commits
• Leave local copy / checkout from
repository ?
• Can be used remotely

3. What to check in
• Do check in source code, third party DLL's
that we are referencing, the VS.NET
solution file, XML files which have the
inline XML comments, and CSPROJ files

4. How to get a copy of the working
copy
• Use the Tortoise SVN 'export' option to
create a copy of the working copy ,
instead of Windows copy and paste

5. What not to commit
• Do not check in DLL's that are a product
of your compilation
• Do not check in SUO's, PDB's since they
are not needed to be versioned or
archived
• Do not commit or add files which have
conflicts

6. How to drop a file from the
repository
• When you wish to delete a file or folder
that has been archived in SVN, use the
Tortoise SVN delete option . Remember
to commit the file / folder after this action
for the deletion to take effect.

7. Frequency of updating
• It is a mandatory practice that you update
and commit your entire SVN client folder
at least twice a day

8. Use a standard client folder
• For the sake of consistency, use the same
folder name in the client to store the
working copy. So, for example, some of
the people use D:/IHCXClient as the folder
to keep working copy

9. Backups
• Backup the working copy of Subversion
once every day. However, if there is a
problem, do not just copy it back.
• System administrator of Subversion can
take a hot backup of the repository in the
server by using the command :
• Svnadmin –hotcopy
SourceRepositoryFolder BackupFolder

10. To rename a file in the repository
• If you want to rename a file, use the
Tortoise's rename option. This will
rename it in the repository as well after
the next commit

11. How to resolve conflicts
• open the file in Notepad or Visual Studio
• resolve the conflict by removing
unwanted lines, retaining the wanted
lines in the conflicted block
• save the file
• click on 'Resolved' popup menu option
• commit the file.

12. If there is a problem …
• Contact the Subversion administrator or
some other user of SVN in the team to
help in recovering from the problem
• Do not suspend the use of Subversion
because of a problem

13. Choose which files to commit
• Always run through the list of files to
commit in Tortoise SVN
• Check the files that you feel are needed to
be committed

14. How to ‘revert’ a file
• If you find a file in the ‘to be committed’ list
which you feel should be the same as in
repository and does not need to be
different, you can use popup menu option
of ‘Revert’. Choose the appropriate
version to revert to.

15. Add
• If you add a file to your working copy
which you want should be part of the
repository, then use the popup menu
option of ‘Add’, and then commit the file.

16. Glossary – BASE revision
• This is the revision the file or folder was in,
when the last checkout, update or commit
was run .

17. Glossary - Branch
• You can create a branch off the main
development line so as to develop a new
feature without rendering the main line
unstable. Or you can branch a stable
release to which you make only bugfixes,
while new developments take place on the
unstable trunk. In Subversion a branch is
implemented as a “cheap copy”.

18. Glossary - Blame
• This command is for text files only, and it
annotates every line to show the
repository revision in which it was last
changed, and the author who made that
change. Our GUI implementation is called
TortoiseBlame and it also shows the
commit date/time and the log message
when you hover the mouse of the revision
number.

19. Glossary - Commit
• This Subversion command is used to pass
the changes in your local working copy
back into the repository, creating a new
repository revision.

20. Glossary BDB
• Berkeley DB. A well tested database
backend for repositories, that cannot be
used on network shares. Default for pre
1.2 repositories.

21. Glossary - Checkout
• A Subversion command which creates a
local working copy in an empty directory
by downloading versioned files from the
repository.

22. Glossary - Copy
In a Subversion repository you can create a
copy of a single file or an entire tree. These
are implemented as “cheap copies” which act
a bit like a link to the original in that they take
up almost no space. Making a copy preserves
the history of the item in the copy, so you can
trace changes made before the copy was
made.

23. Glossary - Export
• This command produces a copy of a
versioned folder, just like a working copy,
but without the local .svn folders.

24. FSFS
• FS File system. A proprietary Subversion
file system backend for repositories. Can
be used on network shares. Default for 1.2
and newer repositories.

25. Diff
• Shorthand for “Show Differences”. Very
useful when you want to see exactly what
changes have been made.

26. HEAD revision
• The latest revision of a file or folder in the
repository.

27. Glossary - Patch
• If a working copy has changes to text files only,
it is possible to use Subversion's Diff command
to generate a single file summary of those
changes in Unified Diff format. A file of this type
is often referred to as a “Patch”, and it can be
emailed to someone else (or to a mailing list)
and applied to another working copy. Someone
without commit access can make changes and
submit a patch file for an authorized committer to
apply. Or if you are unsure about a change you
can submit a patch for others to review.

28. Glossary - Merge
– The process by which changes from the
repository are added to your working copy
without disrupting any changes you have
already made locally. Sometimes these
changes cannot be reconciled automatically
and the working copy is said to be in conflict.
– Merging happens automatically when you
update your working copy. You can also
merge specific changes from another branch
using TortoiseSVN's Merge command.

29. Glossary - Switch
• Just as “Update-to-revision” changes the
time window of a working copy to look at a
different point in history, so “Switch”
changes the space window of a working
copy so that it points to a different part of
the repository. It is particularly useful when
working on trunk and branches where only
a few files differ. You can switch your
working copy between the two and only
the changed files will be transferred.

30. Glossary - Update
• This Subversion command pulls down the
latest changes from the repository into
your working copy, merging any changes
made by others with local changes in the
working copy.

31. Glossary – Working Copy
• This is your local “sandbox”, the area
where you work on the versioned files,
and it normally resides on your local hard
disk. You create a working copy by doing
a “Checkout” from a repository, and you
feed your changes back into the repository
using “Commit”.

32. Glossary - Property
• In addition to versioning your directories and
files, Subversion allows you to add versioned
metadata - referred to as “properties” to each of
your versioned directories and files. Each
property has a name and a value, rather like a
registry key. Subversion has some special
properties which it uses internally, such as
svn:eol-style. TortoiseSVN has some too, such
as tsvn:logminsize. You can add your own
properties with any name and value you choose

33. Glossary - Import
• Subversion command to import an entire
folder hierarchy into the repository in a
single revision.

34. Glossary - Relocate
• If your repository moves, perhaps because you
have moved it to a different directory on your
server, or the server domain name has changed,
you need to “relocate” your working copy so that
its repository URLs point to the new location.
• Note: you should only use this command if your
working copy is referring to the same location in
the same repository, but the repository itself has
moved. In any other circumstance you probably
need the “Switch” command instead.

35. Glossary - Revision
• Every time you commit a set of changes,
you create one new “revision” in the
repository. Each revision represents the
state of the repository tree at a certain
point in its history. If you want to go back
in time you can examine the repository as
it was at revision N.

36. Glossary - Lock
• When you take out a lock on a versioned
item, you mark it in the repository as
uncommittable, except from the working
copy where the lock was taken out.

37. Glossary - Cleanup
• To quote from the Subversion book: “
Recursively clean up the working copy,
removing locks and resuming unfinished
operations. If you ever get a working copy
locked error, run this command to remove
stale locks and get your working copy into
a usable state again. ” Note that in this
context “lock” refers to local file system
locking, not repository locking.

38. Integration with Bug Tracking
• To tag each commit to a Bug ID, you can
set one these one of these properties
while configuring Subversion :-
• bugtraq:url : Set this property to the url of
your bugtracking tool. It must be properly
URI encoded and it has to contain
%BUGID%
• http://issues.tortoisesvn.net/?
do=details&id=%BUGID%

39. Integration with bug tracking
• bugtraq:warnifnoissue
• Set this to true, if you want TortoiseSVN to
warn you because of an empty
issuenumber textfield. Valid values are
true/false. If not defined, false is assumed.

40. Integration with Bug Tracking
• bugtraq:message
• This property activates the Bugtracking
System in Input field mode. If this property
is set, then TortoiseSVN will prompt you to
enter an issue number when you commit
your changes

41. Integration with Bug Trackers
• bugtraq:logregex
• This property activates the Bugtracking
System in Regex mode. It contains one or
two regular expressions, separated by a
newline
• If only one expression is set, then the bare
bug ID's must be matched in the groups of
the regex string. Example: [Ii]ssue(?:s)?
#?(d+)

42. Tools to integrate with VS.NET
• AnkhSVN
• VisualSVN