Subversion Basics

1
Subversion Basics

• How to use the Subversion Source Control System

2
Getting Access

• Wiki groups
• The access rules have changed since the
  documentation was written
• Note TortoiseSVN 1.4 has been released you
  might want to upgrade

3
Your working copy

• The working copy is the copy of the source code
  which you have checked out from the server
• Base revision the revision which you check out
  from the repository, typically the head revision
• Head revision the most current (highest
  numbered) revision stored on the SVN server

4
The Work Cycle

• The most basic subversion work cycle is designed
  to minimize developer conflict and maximize code
  throughput.
• Other work cycles have different goals, and may
  be suitable for different projects
• They will not be discussed here, but can be
  easily learned with a solid understanding of
  basic SVN techniques

5
Work Cycle, contd.

• Check out
• Update
• Edit
• Review
• Resolve
• Commit

6
(No Transcript)
7
Update

• The most important part of the work cycle.
• You MUST update your working copy before you
  begin editing.
• Well, not really. But that is also beyond the
  scope of the documentation.

8
Edit

• Self-explanatory make changes to your
  repository.
• For project files created by the IDE, it may be
  necessary to add files to the ignore list

9
An aside the dialog box

• Get used to this box.

10
Review Locally

• Review your changes before you commit, as well
  as differences between your working copy, and the
  base revision of your working copy.

11
Review against head revision

• This will give you an idea of what has changed in
  the head revision since you checked out your
  working copy.
• At this point, you can still change your source
  to avoid conflicts
• Sometimes, its better to change your code before
  a commit to avoid duplication of work, rename
  variables, etc.

12
(No Transcript)
13
Conflicts

• Conflicts occur when two developers have modified
  a file in the same place.
• Differences in other parts of the file are merged
  automatically
• A clean merge does not mean a clean compile!

14
Conflicts, contd.

• If the review against the head revision showed
  that your base revision and the head revision
  have the same number, go ahead and commit.
• Else, update!
• If you try to commit against a head revision of
  42 with a base revision of 40, it will not
  commit.
• Update!

15
Conflicts, contd.

• On update, any files whose changes cannot be
  merged automatically will enter a conflicted
  state
• You must resolve this conflicted state before you
  commit again
• There are three ways to resolve a conflict
• Revert
• Accept new changes
• Merge changes by hand

16
Conflicts, contd.
17
Conflicts, contd.

• A conflicted state creates three new files
• Aside you may want to turn off hide extensions
  for known files
• These files will be
• A copy of your changes
• A copy of the file from the new base revision
• A copy of the file from the head revision
• If the conflicted file is main.c, the new files
  will be called
• Main.c.mine
• Main.c.rOLDREV
• Main.c.rNEWREV

18
Conflicts, contd.

• The conflicted file itself, main.c, will have
  conflict markers automatically inserted.
• These markers will show both your new revision
  and the head revision for the conflicted section.

19
Resolution checking the logs
20
Resolution SVN revert

• When you revert a file, it will return to the
  base revision. You will lose all your changes.
• Be careful to only revert the files that you mean
  to There is no good way of getting your changes
  back

21
Resolution temporary files

• As previously mentioned, three new unversioned
  files are created for each conflicted file.
• You may delete the conflicted file, main.c, and
  rename one of the temporaries to main.c.
• By renaming main.c.mine, you throw away all other
  changes, accepting only yours.
• By renaming main.c.rOLDREV, you are throwing away
  all changes made to the file since revision
  OLDREV
• By renaming main.c.rNEWREV, you are reverting
  to the head revision and accepting all the new
  changes at the expense of your own.

22
Resolution, by hand

• This is straightforward edit the conflicted
  sections by hand using the conflict tags as a
  guide.
• Dont leave conflict tags in the file. Whatever
  is in your file will become the new head
  revision, and conflict tags are not likely to
  compile

23
Resolution, SVN resolve

• When something is marked as resolved, the
  conflicted state is simply lifted, the temporary
  files are deleted, and whatever is in the
  conflicted file will be committed to the
  repository
• Deleting the temporary files is the same thing as
  marking a file resolved
• If a file is reverted, it is automatically marked
  as resolved.

24
Commit

• Once you are finished resolving any conflicts,
  commit your changes.

25
Commit

• Make sure to write a log entry describing your
  changes
• Log entries are the only way to quickly track the
  nature of changes made to the repository
• Empty log messages will not be accepted by the
  server