Week 2

• DUE This Week: Safety Form and Model Release• DUE Next Week: Project Timelines and Website• Notebooks• Lab Access• SharePoint Usage• Subversion• Software Conventions and Documentation (Grading)

Subversion

©David Turner

What is Subversion?

• Subversion is a version control system.• A version control system allows users to manage

files, directories, and the changes made to them.• Subversion can manage any sort of file collection (not

only source code).

Working copy

Working copy

Working copy

Repository

Internet

Reasons to Use Subversion

• You can work more easily with other developers on software development projects.

• You can undo changes to obtain earlier versions of files.

• Subversion is well known and free.• Subversion has been under development since 2000.

Why SVN in EPICS?

• All software teams currently share an SVN server that is already ready to go

• SVN is still widely used in Purdue coursework• The “centralized” nature is easy to comprehend and

manage for new users of VCS (vs. Git’s distributed repos)

• Less complicated than Git (and therefore less flexible)

Repository versus Working Copy

• Project code is stored in a server in a data store referred to as a “repository.”

• Developers “check out” copies of the project code into their local environments. These copies are referred to as “working copies.”

• After making changes to a working copy, the developer “commits” changes to the repository.

• Other developers get these changes by “updating” their working copies.

Differentials (“Diffs”)

∆∆

currentversion

previousversion

previousto thepreviousversion

∆

Atomic commits

• A collection of modifications either goes into the repository completely, or not at all.

• In other words, a commit will either altogether succeed, or it will altogether fail.

Properties

• Each file and directory has a set of properties—keys and their values—associated with it.

• You can keep certain files from being written into the repository by setting the svn:ignore property to a string that matches the files you want to omit. Such files are said to be “unversioned.”

• IMPORTANT: Properties like permissions may not sync correctly without being explicit

Multiple Developers: Old Style

• User A gets a copy of file X from the data store.

• User B gets a copy of file X from the data store.

• User A changes X and writes the new X back into the data store.

• User B changes his older version of X and writes this into the data store, over-writing A’s changes.

Multiple Developers: Copy-Modify-Merge

• Subversion uses a copy-modify-merge approach instead of locking.• User A gets a “working copy” of X.• User B gets a “working copy” of X.• User A changes his working copy of X.• User B changes her working copy of X.• A saves his copy of X into the repository.• B tries to save his copy of X into the repository, but it fails, because her

changes were made to a now stale version of X• B performs an “update,” which results in A’s changes to X to be merged

into B’s version of X.• If A’s changes do not conflict with B’s changes, the update silently

completes. If A’s changes conflict with B’s changes, subversion inserts annotation into X describing the conflicts and then reports the problem to B. B then manually resolves the conflict.

• Whether B needed to manually resolve conflicts or not, the next step is for B to commit her changes into the repository, which now succeeds.

Copy-Modify-Merge in Practice

• With copy-modify-merge, users do not wait on each other.

• In practice, conflicts are rare and are usually straightforward to resolve.

• Copy-modify-merge does not work well with binary files, because changes can not be merged. For this reason, subversion provides a lock-modify-unlock process when needed.

Revisions

• Subversion transactions are atomic: they either succeed entirely or fail entirely

• After the repository is initially created, it is an empty folder and has revision number 0.

• After committing to a repository with revision number n, the repository is changed to version n+1.

Revisions and Working Copies

• Working copies do not always correspond to any single revision of the repository; they may contain files from several different revisions.

Revisions and Working Copies• User A checks out repository repo.

repo/system.h3repo/system.cpp 3

• User A modifies system.h and commits this file.

repo/system.h4repo/system.cpp 3

• User B commits changes to system.cpp, and A updates.

repo/system.h5repo/system.cpp 5

Local File States and Consequences

update commit

Unchanged, and current

does nothing does nothing

Locally changed, and current

does nothing writes changes into repo

Unchanged, and out-of-date

replaces working file with new one

does nothing

Locally changed, and out-of-date

merges changes into working file

operation fails with out-of-date error

Branching and Merging

• Something to note, but may not run into often for our Projects

• Branches represent different timelines of the repository that can be merged later on.

• Useful for a lot of changes to the “trunk”• Useful for splitting up large modular features• Git is all about merging and branching

especially locally