Subversion

2,221 views
2,162 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,221
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
74
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Subversion

  1. 1. Subversion Dos and don'ts
  2. 2. Advantages of SVN over VSS • Atomic commits • Leave local copy / checkout from repository ? • Can be used remotely
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. Glossary – BASE revision • This is the revision the file or folder was in, when the last checkout, update or commit was run .
  17. 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. 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. 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. 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. 21. Glossary - Checkout • A Subversion command which creates a local working copy in an empty directory by downloading versioned files from the repository.
  22. 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. 23. Glossary - Export • This command produces a copy of a versioned folder, just like a working copy, but without the local .svn folders.
  24. 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. 25. Diff • Shorthand for “Show Differences”. Very useful when you want to see exactly what changes have been made.
  26. 26. HEAD revision • The latest revision of a file or folder in the repository.
  27. 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. 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. 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. 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. 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. 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. 33. Glossary - Import • Subversion command to import an entire folder hierarchy into the repository in a single revision.
  34. 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. 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. 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. 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. 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. 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. 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. 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. 42. Tools to integrate with VS.NET • AnkhSVN • VisualSVN

×