SVN Usage & Best Practices
Upcoming SlideShare
Loading in...5
×
 

SVN Usage & Best Practices

on

  • 14,704 views

 

Statistics

Views

Total Views
14,704
Views on SlideShare
14,674
Embed Views
30

Actions

Likes
4
Downloads
284
Comments
0

3 Embeds 30

http://www.slideshare.net 17
http://www.linkedin.com 10
https://www.linkedin.com 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

SVN Usage & Best Practices SVN Usage & Best Practices Presentation Transcript

  • Source control using SVN Prepared by Ashraf Fouad
  • Agenda
    • Client
    • (What / Why) source code control?
    • Known SCC software.
    • Why SVN?
    • Sites / Required software.
    • Basic terminology / actions.
    • Basic life cycle.
    • Client setup / connectivity.
    • Client usage.
    • Advanced actions.
    • Server
    • Setup.
  • What source code control (SCC)?
    • What:
      • Like shared network drive, but controlling access to files between team members.
      • Merging different versions of code modified by several developers on text based level difference.
      • Tracking changes (viewing history).
      • Provide backup / restore points (short/long) term undo.
      • Provide branching / Merging.
      • Provide synchronization / locks / notifications.
      • Provide HTTP / remote access.
    • Not for teams only even a single developer benefit from SCC as it makes backup of different versions of source code.
  • Why source code control (SCC)?
    • Why:
      • Shared network is not handling several developers accessing same file.
      • Avoid using vague words that always change as latest, final, pre-final, v1, or dates to file that will prevent them of compiling.
      • Keeping several versions for code for several reasons:
        • Product versions, its patches.
        • Maintain customization of product for several clients.
        • Allow the freedom to experiment or make Proof of concept without fear of losing control over code.
    • Some surveys indicate that 70% of software teams doesn't use SCC, I can't imagine how they cope ==> At the end it will be your call to decide, although I don't think you can survive ;)
  • Known SCC software
    • CVS (Concurrent Versions System) .
    • Microsoft Visual SourceSafe .
    • SVN (Subversion) .
    • IBM Rational ClearCase .
    • Borland StarTeam .
    • This presentation is dedicated for centralized source code control, we are not discussing distributed repository architecture.
    • The naming convention is not always the same for all SCC software, the naming convention used here will be for SVN.
    • In most companies using SCC, it is not only used for code, but also, requirements, analysis, design, test scenarios, etc...
  • Why SVN?
    • Powerful with command line interface.
    • Free / open source.
    • Availability of free client software / Plugin for most known IDEs.
    • SVN is simpler than CVS by eliminating some not commonly used functionality.
    • Faster.
    • DB based not file based.
    • Customized attributes to be attached to files.
    • Automatically handles all file types without instructions.
    • Support Folder / File rename & copies maintaining the history.
  • Sites / Required software
    • Official site: SVN
    • Free server edition: VisualSVN Server
    • Free GUI client:
      • Eclipse Plugin ( Subclipse ).
      • Standalone free client most famous TortoiseSVN .
      • Standalone free / commercial SmartSVN .
    • Lots of sites offering hosting SVN ( Offering SVN ) (Free / Commercial).
  • Basic terminology / actions
    • Server:
      • Repository.
      • Trunk / Main.
    • Client:
      • Working copy.
      • Add / Check-out / Check-in.
      • Check-in message.
      • Revision / Head.
      • Change log.
      • Update / Synchronize.
      • Revert.
  • Basic life cycle (Edit-Merge-Commit) No Rev Rev 1 Rev 1 Modified Rev 2 Repository Working folder Merged
  • Basic life cycle (Edit-Merge-Commit) (cont.)
    • The following rules applies:
      • Files in the working folder are all writable.
      • Nobody knows who is editing the files.
      • While developer commits, he is responsible for ensuring that his changes were made against the latest version in repository.
    • This life cycle is risky in the manner that the merge step may be tedious or cause problems. However, the acceptance of this risk rewards us with a concurrent development style.
    • Merge is only required when team members are working in parallel in the same file, usually it is better to do the merge manually rather than doing automatic merge supplied by different client tools.
  • Merge example Rev 4 Repository Dev 2 Working folder Dev 1 Working folder Rev 5 Rev 5 Rev 5 Modified 5 by dev 1 Modified 5 by dev 2 Rev 6 Modified 5 By dev 2 merge with Rev 6 Rev 7
  • Client setup / connectivity for TortoiseSVN
    • TortoiseSVN client (windows installation msi):
      • Install with full integration.
      • You will need to restart after installation.
    • In order to connect:
      • Create a folder that will be your local working folder.
      • In windows explorer, right click, SVN checkout.
      • URL of repository: https://<server-name>:8443/svn/<repository-name>/
      • Checkout folder: Your local working folder.
      • Checkout depth: Fully recursive.
      • Head revision.
      • OK.
  • Client setup / connectivity for SmartSVN
    • SmartSVN client (without jre):
      • Install with full integration.
      • Select Foundation version.
    • In order to connect you need to configure repository profile, with the following information:
      • Protocol: https for Internet connection, SVN for network.
      • Server name: name of server IP.
      • Repository path: /svn/<repository_name> for https, /<repository_name> for network.
      • Port: non-default 8443.
      • Corresponding local folder.
  • Client setup / connectivity for eclipse
    • Eclipse plugin:
      • Right click project -> Team -> Share project.
      • SVN, Next
      • URL: https://<server-name>:8443/svn/<repository-name>/
      • Project name as folder name.
      • Finish.
      • Accept certificate permanently.
      • Enter username / password.
      • We import only source & lib usually, we don't include bin folder.
  • Basic actions
    • Based on your SVN client, you need to practice the following basic actions on the 'trunk' folder:
      • Add / commit.
      • Update / commit.
      • Modify / Revert.
      • Modify several files / commit all with same message.
      • View revision graph / view log.
      • Compare between versions / Show differences.
      • Add folder recursively.
      • Update local copy to specific revision not just head.
      • Delete / commit – Delete / revert deletion.
    • You need to get used for the icons on files for your favorite SVN client, you should find list in the help of the client software.
  • Basic actions (cont.)
    • Continue to practice the following tasks:
      • Lock – Modify – Unlock to prevent anyone from changing in file while you are modifying it.
      • Export to be used when releasing for taking version.
      • Try the blame feature to view changes for each line is done by whom.
  • Advanced actions
    • Branching:
    • Needed when your development team needs to work on two distinct copies of a project at the same time & keep the two lines of development distinct, example:
      • Development of release 2.0
      • Maintenance of release 1.0
    • Atomic transactions (Changeset).
    • Resolving conflict (Best get latest version & apply changes again).
    • Reverse Integrate (Merge branch in trunk).
    • Forward Integrate (Merge trunk in branch).
  • Advanced actions (cont.)
    • Tag / Release: Light weight, usually used as naming a release for a folder and its sub-folders to identify meaningful release (example: Build.1.2.03.prod).
  • Best practice
    • Take it slow.
    • Be precise and exhaustive in your commit comments, try to have a standard for your company.
    • Commit your work to the repository as often as you can without breaking the build. Always check-in a compiled version of code in order not to prevent others from continuing work if updated their working folders. Don't let your working folder become too valuable.
    • Keep in touch with the repository i.e. update your working folder as often as you can without interrupting your own work. It isn't wise to let the distance between your working folder and the repository grow too large.
    • If you used merge, merge manually & make sure you have a compiling version before commit.
  • Best practice (cont.)
    • Small project: Don't branch or merge.
    • Don't create a branch unless you are willing to take care of it.
    • Big projects: Usually have experienced maintainers who keep track of branches or patches.
    • Make always your repository root having 3 sub-folders (trunk, branches, tags).
    • Don't make branches to keep track of specific customers, better to build customizability in your application.
    • Always group your check-in logically (Bug fix, add feature, particular task).
  • VisualSVN Server setup
    • Run installer “VisualSVN-Server-x.x.x.msi”.
    • Next, I accept, Next.
    • Specify location for installer (Require nearly 7 MB).
    • Specify location for repository (Require large space for your files).
    • Select authentication type based (Either own subversion users, or windows users) you may need to consult your system admin before decide.
    • Next, Install.
    • Finish.
  • VisualSVN Server setup (cont)
    • What happened after installation:
      • Service created VisualSVN Server created Automatic startup.
      • Repository folder contains 5 files now.
  • Repository (Server) information
    • Repository = File system x time
    • Usually the repository store delta between files for each check-in (Either forward or reverse delta or sometime make some combination).
    • Backup: dump versus hotcopy.
      • When you dump, it checks out every single revision in the repository.
      • hotcopy is a file copy of your repository database.
  • Questions / Suggestion Thanks Ashraf Fouad
  • References
    • A Visual Guide to Version Control .
    • Source control how to .
    • SVN best practice .
    • 5 SVN best practices .
    • OSCON: Subversion Best Practices .
    • Version control with subversion .