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 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. Gits 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) current version previous version previous to the previous version

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 valuesassociated 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.h3 repo/system.cpp3 User A modifies system.h and commits this file. repo/system.h4 repo/system.cpp3 User B commits changes to system.cpp, and A updates. repo/system.h5 repo/system.cpp5

Local File States and Consequences updatecommit Unchanged, and current does nothing Locally changed, and current does nothingwrites 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