WANdisco Free Subversion Training: Getting Started with SVN

  • 1,475 views
Uploaded on

WANdisco Free Subversion Training …

WANdisco Free Subversion Training

Webinar: Getting Started With Subversion

Date: January 24 2013

Going back to basics! This course is intended as a primer for new users or people who are thinking of making the jump to Subversion. This will be a short introduction to the way Subversion works.

All the topics that a new user needs to be exposed to. Topics covered:

- Repository basics, creating and organizing
- Checkouts, working folders, editing files and checkins
- Reporting on changes
- Simple branching
- Simple merging

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,475
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
45
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 4 clicks
  • 3 clicks
  • 1 click
  • 2 clicks
  • 1 click
  • 1 Clicks
  • 4 Clicks
  • 1 Click
  • 3 Clicks
  • 2 clicksShow next webinar

Transcript

  • 1. Getting Started withSubversion Presenter Michael Lester Wandisco Director of Training
  • 2. Getting Started withSubversion
  • 3. Outline  Subversion Components  Projects Layout  Usual work cycle  Setup, checkout, commit demonstration  Branching  Merging  Branching and merging demonstration 3
  • 4. This training is done with the latestTortoiseSVN Version http://www.wandisco.com/subversion/download
  • 5. Subversion Components Working Copy SVN.EXE Repository Working Copy TortoiseSVN Working Copy Repository A private central location of all versions of a project’s files. The work area created by checking out from Subversion 5
  • 6. Subversion Organization Repositories Projects Folders Files (subFolders) 6
  • 7. Subversion Repositories Repositories • Can have a single or multiple repositories • Can be on a server or local • Can have access security 7
  • 8. Subversion Projects Projects • Relates to a top level folder/directory • Should have meaningful names • Created (in repository) by the “IMPORT” or “COPY” command 8
  • 9. Subversion Directories Folders • How projects are organized, just like folders • Organized hierarchically • Created automatically via the “IMPORT” command or “CREATE FOLDER” command 9
  • 10. Subversion Files Files • The end point • All files must be in some directory • Can exist in the repository and any number of working copies 10
  • 11. Repository Layout  Many options  Main goal – minimize errors  Other goals  Reusability  Ease of use  Should be part of “Policies and Procedures”  Standardization easier on Admin tasks  Too many objects per level can be confusing 11
  • 12. Repository Layout - the TTB Layout / --- root mail trunk tags trunk – Main line development branches calculator tags – Snapshots in time trunk branches – Special / temporary tags projects branches spreadsheet trunk tags branches 12
  • 13. Repository Layout - Project Layout Example calculator trunk tags rel 1.0 rel 1.1 rel 2.0 branches mike test_new_DB_access bugfix_rel 1.1 rel 2.1 cust_page_change QA rel 2.0 05_23_2010 rel 2.0 06_13_2010 13
  • 14. Populating the Repository Repository  This may be done by the users or admin  Two methods  IMPORT command  CREATE FOLDER (MKDIR) command 14
  • 15. IMPORT Command May require a log message 15
  • 16. Create Folder (MKDIR) Command  May require a log message 16
  • 17. Working Copy Working Copy Working Copy This is created and maintained by Subversion. .svn folder - Means this is a working copy folder You should never need to access this area, but you should NEVER delete it either. 17
  • 18. The Usual Work Cycle Check out Commit Edit Update 18
  • 19. Check Out This step gets the latest repository Check out version of a project, directory or file and copies it to a location where it Commit Edit can be edited. Update 19
  • 20. Check Out Check out Commit Edit Update Two main parameters Where Where to from Current Relative Qualified Repository Directory Directory Directory 20
  • 21. Check Out Check out Commit Edit Update Two decisions to make Where from Where to Create a Current New Directory Directory 21
  • 22. Creating a Working Copy The checkout command creates a working copy folder. 22
  • 23. Results of Checkout Common Errors • Picking a level too high • Selecting an existing working directory • Checking out before doing a commit • Picking wrong Repository or project 23
  • 24. Indicates a fresh checked-out working copy of thisfileIndicates a file has been modified since it waschecked-out, and therefore needs commitingIndicates a conflict while updating filesIndicates a svn:needs-lock property on the file.I.e. it is read-only. Same symbol(You need to get a lock before you can edit thisfile) for folder or fileIndicates a locked, but normal file. This symbolreminds you that you should unlock it for others toaccess itIndicates that some files/folders inside a folderare scheduled for deletion, or a file under versioncontrol is missing in a folderIndicates that a file or folder is scheduled to beadded to version control 24
  • 25. Scenario• project1 checked out to c:sourceproject1_mike• project1 checked out to c:sourceproject1_sue• project1_mike jobs.txt changed• days.txt added• props.txt deleted• project1_mike committed Are there any changes? 25
  • 26. Remember, to compare this project with therepository you need to select this option. 26
  • 27. Check out Downloads all changes thatCommit Edit have been made to files in the Subversion repository to your Update local copy. update Local Repository (working) copy 27
  • 28. Possible Update Effects Check out Commit Edit Update 28
  • 29. Possible Update Effects Check out Commit Edit Update 29
  • 30. Possible Update Effects 30
  • 31. Possible Update Effects Comparing two versions 31
  • 32. Diff doesn’t work on binary files 32
  • 33. Add a Work File Adding a file to a working directory does NOT add it to version control. You need to use the SVN add command to let Subversion know it is part of version control. Before svn ADD After svn ADD 33
  • 34. Delete Work File Deleting a file in a working directory does NOT remove it from version control and the repository. You need to use the svn DELETE command to let Subversion know it is no longer part of version control. 34
  • 35. Delete File from Repository Deleting a file from the repository does not remove it from the working directory. It does remove it from version control. 35
  • 36. Commit Check out Committing is where you store a set Commit Edit of changes into the repository. Update Local (working) copy commit Repository 36
  • 37. Commit When you commit multiple files they all are tagged by the newly created version number. Both files are marked at revision 19 . 37
  • 38. Revisions Repository The repository Projects and everything in it go through revisions Directories 1,2,3,4,…. Files 38
  • 39. Atomic Revisions All changes, adds, modifications, and deletions, are part of the same revision (10). 39
  • 40. Atomic Revisions Selecting the revision will show all changes incorporated by that revision. 40
  • 41. Branching, Merging and Conflicts• Branches – What are they – Why we need them• Merging – When to merge – When we never merge – How to merge• Conflicts – Detecting conflicts – Resolving conflicts 41
  • 42. What is a BranchThe basic concept of a branch: A line of development that exists independently of another lineA branch always begins life as a copy of something,and moves on from there, generating its own history. 3rd branch 1st branch Original line of development 2nd branch 42
  • 43. Why we Need Branches Branches are needed so that separate development efforts can take place at the same time. Without branching we could never merge. Branches make the development process easier and more understandable. 43
  • 44. Creating Branches in Subversion Starting repository database trunk branches Let’s assume that Tom wants to start working on the next release 44
  • 45. Creating Branches in Subversion Repository after the copy command Payroll Tom can now check out the project starting at “tomNext” trunk and know that any changes he makes will not effect anyone working on the “trunk” project” branches tomNext 45
  • 46. Merging in Subversion Definition: Applying the differences between two sources to a working copy path.Example: svn merge file:///c:/svnrepos/projectOne -r346:348 foo.c 46
  • 47. Merging Example Step 1. A development project is underway. A single file is 1 2 3 represented. This file shows the list of offices in the company. offices.txt Since the beginning of this project we have made two changes. 47
  • 48. Merging Example 3 4 5 Step 1. Note: Revision 1 & 2 Created the trunk and branch folders 48
  • 49. Merging Example Step 2. Create a new directory / branch named “Rel1.0”. Add this to the Rel 1.0 repository folder “Branch” After this, both the trunk and the new branch are changed TRUNK independently. For illustration, lets pretend that In the trunk a new office is added and in Rel1.0 a misspelling is corrected. 49
  • 50. Merging Example 4 5 Rel 1.0 TRUNK Step 2. 50
  • 51. Merging Example Step 3. Rel 1.0 A change is made to the latest version in the trunk directory. A new office location is added. TRUNK 51
  • 52. Merging Example The person responsible for Step 4. “Rel 1.0” tells the person responsible for the “TRUNK” Rel 1.0 that they fixed a line of the file that should be propagated (MERGED) into the “TRUNK” .TRUNK Actually the merge happens into the workfile, then the workfile is committed back into the repository. 52
  • 53. Merge Clarification Step 4. Rel 1.0 The merge DOESN’T EVER Merge create a new version. A merge ALWAYS modifies a workfile. The workfile can then beTRUNK Workfile committed to the repository, which creates a new version. We just show The workfile created by the it like this for merge may be edited before the simplification commit. 53
  • 54. Merging Example Rel 1.0 Step 4. 4 5 TRUNK 54
  • 55. Conclusions 1. Practice on a temporary repository 2. Implement Subversion on real projects. 3. Get additional info, training, reading etc. 4. Create “Policies & Procedures” 5. Modify “Policies & Procedures” as you get more experienced. 55
  • 56. Feb 14th Branching Options for Development Presenter February 28th Michael Lester Wandisco Getting Info Director of Training Out of SubversionCopyright © 2011 WANdisco All rights reserved. 56
  • 57. What’s Next… Our Support Engineers are the Sherpas SmartSVN is the world’s most popular of Source Control Management. SVN client for Linux, Mac and Windows. WANdisco support contracts include: SmartSVN Professional includes: • Subversion Access Control • Out of the box features • Core SVN Developers & Git experts • A permanent license Key on staff • One year of free updates • Guaranteed response times • One year of free email support • Indemnification coverage www.smartsvn.com/buy www.go/wandisco.com/getting- started-support-offer 57