Source Code Management & Subversion

1. Source Code Management& Subversion CS420 – Spring 2011

2. Versioning Models • Core mission of a version control system is to enable collaborative editing and sharing of data. • Different systems use different strategies to achieve this.

3. The Problem of File-Sharing • How will the system allow users to share information, but prevent them from accidentally stepping on each other's feet?

4. Problem to Avoid 2 co-workers: Harry and Sally • Each decides to edit the same repository file at the same time. • If Harry saves his changes to the repository first, then it's possible that (a few moments later) Sally could accidentally overwrite them with her own new version of the file. • While Harry's version of the file won't be lost forever (because the system remembers every change), any changes Harry made won't be present in Sally's newer version of the file, because she never saw Harry's changes to begin with. • Harry's work is still effectively lost—or at least missing from the latest version of the file—and probably by accident

5. Problem to Avoid

6. The Lock-Modify-Unlock Solution The repository allows only one person to change a file at a time. • First Harry must “lock” the file before he can begin making changes to it. Locking a file is a lot like borrowing a book from the library; if Harry has locked a file, then Sally cannot make any changes to it. • If she tries to lock the file, the repository will deny the request. All she can do is read the file, and wait for Harry to finish his changes and release his lock. After Harry unlocks the file, his turn is over, and now Sally can take her turn by locking and editing.

7. The Lock-Modify-Unlock Solution

8. Problems with Lock-Modify-Unlock • Locking may cause administrative problems. Sometimes Harry will lock a file and then forget about it. Sally is still waiting to edit the file, her hands are tied. And then Harry goes on vacation. Now Sally has to get an admin to release Harry's lock. • Locking may cause unnecessary serialization. What if Harry is editing the beginning of a text file, and Sally simply wants to edit the end of the same file? These changes don't overlap at all. They could easily edit the file simultaneously, and no great harm would come, assuming the changes were properly merged together. • Locking may create a false sense of security. Pretend that Harry locks and edits file A, while Sally simultaneously locks and edits file B. But suppose that A and B depend on one another, and the changes made to each are semantically incompatible. Suddenly A and B don't work together anymore. The locking system was powerless to prevent the problem—yet it somehow provided a false sense of security. It's easy for Harry and Sally to imagine that by locking files, each is beginning a safe, insulated task, and thus inhibits them from discussing their incompatible changes early on.

9. The Copy-Modify-Merge Solution • Each user's client contacts the project repository and creates a personal working copy—a local reflection of the repository's files and directories. • Users then work in parallel, modifying their private copies. • Finally, the private copies are merged together into a new, final version. The version control system often assists with the merging, but ultimately a human being is responsible for making it happen correctly.

10. The Copy-Modify-Merge Solution

11. The Copy-Modify-Merge Solution

12. Problems with the Copy-Modify-Merge Solution • Conflict: Sally's changes overlap with Harry's changes? What then? • When Harry asks his client to merge the latest repository changes into his working copy, his copy of file A is somehow flagged as being in a state of conflict: he'll be able to see both sets of conflicting changes, and manually choose between them. • Note that software can't automatically resolve conflicts; only humans are capable of understanding and making the necessary intelligent choices.

13. Copy-Modify-Merge free tools: CVS (current version system), Subversion

14. Why Use Subversion? (CVS vs SVN) • Functional replacement for CVS • Directory versioning (renames and moves) • Atomic commits (all or nothing) • Faster network access (binary diffs) • File & directory meta-data • Requires less network access

15. Subversion Client Side • Each working directory has a .svn directory • Similar to CVS’s CVS directory • Repository password stored in each .svn • Stores a pristine copy of each file in directory

16. Working Copies • A working copy is an ordinary directory tree on your local system, containing a collection of files. You can edit these files however you wish. Your working copy is your own private work area: Subversion will never incorporate other people's changes, nor make your own changes available to others, until you explicitly tell it to do so. • After you've made some changes to the files in your working copy and verified that they work properly, Subversion provides you with commands to “publish” your changes to the other people working with you on your project (by writing to the repository). If other people publish their own changes, Subversion provides you with commands to merge those changes into your working directory (by reading from the repository). • A working copy also contains some extra files, created and maintained by Subversion, to help it carry out these commands. In particular, each directory in your working copy contains a subdirectory named .svn, also known as the working copy administrative directory. The files in each administrative directory help Subversion recognize which files contain unpublished changes, and which files are out-of-date with respect to others' work. • A typical Subversion repository often holds the files (or source code) for several projects; usually, each project is a subdirectory in the repository's filesystem tree. In this arrangement, a user's working copy will usually correspond to a particular subtree of the repository

17. Subversion Architecture • Two locations of SVN repositories • On a local filesystem • Typically used for a single developer • Accessed via direct file read/write access • Requires that users have local accounts • Uses filesystem and user/group security • On a remote system • Accessed via a HTTP or HTTPS connection • Does not require that users have accounts on the server • Use Apache style authentication

18. Subversion Server Design • Server uses Apache web server • Browse repository with Internet Explorer or Netscape • Repository uses Berkeley Database • Data integrity • Atomic writes • Recoverability • Hot backups

19. Subversion Command Line Differences • CVS • Argument position matters % cvs –d /export/home1/cvs update –d • SVN • Argument position does not matter % svn log –r 123 foo.c % svn log foo.c –r 123

20. Getting Started $ svnadmin create /usr/local/svn/newrepos The svn import command is a quick way to copy an unversioned tree of files into a repository, creating intermediate directories as necessary $ svn import mytree file:///usr/local/svn/newrepos/some/project $ svn ls file:///usr/local/svn/newrepos/some/project

21. How Do Revisions Work? (Part 1) • Revision numbers are applied to an object to identify a unique version of that object • Example files % ls bar.c foo.c • CVS • Revision numbers are per file • A revision number from one file does not necessarily have any meaning to another file with the same revision number • A commit only updates the revision numbers of files that were modified • bar.c may be at revision 1.2 and foo.c at 1.10 • Updates to bar.c will not change foo.c’s revision number

22. How do revision Work?

23. How Do Revisions Work? (Part 2) • Subversion • Revision numbers are global across the whole repository • Identify how the entire repository looks at that instant in time • A commit creates a snapshot of the entire tree in the repository at that revision number • Allows users to say, “Hey so-and-so, go get revision 1432 of XYZ and try to compile it.” • Before an update, both bar.c and foo.c are at revision 25 • Modify bar.c and commit • Then update the working copy • Now bar.c and foo.c are at revision 26, except that foo.c in revision 25 and 26 are identical • No additional space in repository required, i.e. a cheap copy or a symbolic link is made

24. How Do Revisions Work? (Part 3) • Example revision update • Check out tree % svn co file:///home/orest/repos/cs420 A Makefile A document.c A search.c Checked out revision 4. • Edit search.c % vi search.c • Commit the edit % svn commit –m “Add better search” Sending search.c Transmitting data… Committed revision 5.

25. How Do Revisions Work? (Part 4) • Status of files and directories • Directory `.’ is at 4 but revision 5 exists in the repository • Makefile is at 4 • document.c is at 4 • search.c is at 5 • Get info on a particular file or directory % svn info . Path: . Url: file:////tmp/repos/demo Revision: 4 Node Kind: directory Schedule: normal Last Changed Author: Steve Last Changed Rev: 4 Last Changed Date: 2002-08-08 12:20:18 -0700 (Thu, 08 Aug 2002)

26. How Do Revisions Work? (Part 5) • Now update document.c • Update working copy % svn update U ./document.c At revision 6.

27. Basic Work Cycle (Part 1) • Checkout a working copy • Update working copy • Make changes • Examine your changes • Merge other’s changes • Commit your changes

28. Basic Work Cycle (Part 2) • Checkout a working copy % svn co file:///home/orest/repos/svn % cd svn/doc • Update working copy • Update all files and directories to the most current version % svn update • Go to a particular older revision for all files and directories % svn update –r 1345 • I want an even older version of svn-doc.el % svn update –r 999 svn-doc.el • Update output • U `foo' • File `foo' was (U)pdated (received changes from the server.) • A `foo' • File or directory `foo' was (A)dded to your working copy. • D `foo' • File or directory `foo' was (D)eleted from your working copy. • R `foo' • File or directory `foo' was (R)eplaced in your working copy; that is, `foo' was deleted, and a new item with the same name was added. While they may have the same name, the repository considers them to be distinct objects with distinct histories. • G `foo' • File `foo' received new changes, but also had changes of your own to begin with. The changes did not intersect, however, so Subversion has mer(G)ed the repository's changes into the file without a problem. • C `foo' • File `foo' received (C)onflicting changes from the server. The changes from the server directly overlap your own changes to the file. No need to panic, though. This overlap needs to be resolved by a human (you).

29. Basic Work Cycle (Part 3) • Make changes • Add new files and directories % xemacs bigAlgorithm.c % mkdir data-files % touch data-files/file1 % svn add bigAlgorithm.c data-files # data-files/file1 not added unless –R passed to svn add • Delete files % svn rm foo what_do_they_know.c • Rename file % svn mv README.txt README_OLD.txt # This is identical to % svn cp README.txt README_OLD.txt; svn rm README.txt • Copy files and directories % svn cp test_datafiles test_datafiles_new # If test_datafiles is a directory, then test_datafiles_new # is an exact copy of test_datafiles

30. Basic Work Cycle (Part 4) • Examine your changes • svn status: Normal amount of information % svn status _ L ./abc.c [svn has a lock in its .svn directory for abc.c] M ./bar.c [the content in bar.c has local modifications] _M ./baz.c [baz.c has property but no content modifications] ? ./foo.o [svn doesn't manage foo.o] ! ./foo.c [svn knows foo.c but a non-svn program deleted it] ~ ./qux [versioned as dir, but is file, or vice versa] A + ./moved_dir [added with history of where it came from] M + ./moved_dir/README [added with history and has local modifications] D ./stuff/fish.c [this file is scheduled for deletion] A ./stuff/things/bloo.h [this file is scheduled for addition]

31. Basic Work Cycle (Part 5) • Examine your changes • svn status: More information with -v • First column the same • Second column, working revision • Third column, last changed revision • Fourth column, who changed it % svn status -v M 44 23 joe ./README _ 44 30 frank ./INSTALL M 44 20 frank ./bar.c _ 44 18 joe ./stuff _ 44 35 mary ./stuff/trout.c D 44 19 frank ./stuff/fish.c _ 44 21 mary ./stuff/things A 0 ? ? ./stuff/things/bloo.h _ 44 36 joe ./stuff/things/gloo.c

32. Basic Work Cycle (Part 6) • Examine your changes • svn status: Even more information with -u • Asterisks show if the file would be updated if svn update were run • Requires network access to the repository % svn status -u -v M * 44 23 joe ./README M 44 20 frank ./bar.c _ * 44 35 mary ./stuff/trout.c D 44 19 frank ./stuff/fish.c A 0 ? ? ./stuff/things/bloo.h

33. Basic Work Cycle (Part 7) • Examine your changes • svn diff: Show your modifications • Even shows modifications in properties • Show all differences in files and directories in local working copy % svn diff • Diff between revision 3 of foo.c in repository and local working foo.c % svn diff –r 3 foo.c • Diff between revisions 2 and 3 of foo.c in the repository without even touching local foo.c % svn diff –r 2:3 foo.c • Revert or undo your changes • Does not require network access % svn revert • Commit your changes • Generate a log message containing the files and directories that have been modified % svn status | cut -d/ -f2- > ../message % vi ../message % svn commit –F ../message

34. Conflict Resolution • Look for the ‘C’ when you run svn update • Better than CVS • Conflict markers are placed into the file, to visibly demonstrate the overlapping areas. This matches CVS' behavior. • Three fulltext files starting with `tmp' are created; these files are the original three files that could not be merged together. This is better than CVS, because it allows users to directly examine all three files, and even use 3rd-party merge tools (as an alternative to conflict markers.) • Another improvement over CVS conflict handling: Subversion will not allow you to "accidentally" commit conflict markers, as so often happens in CVS. Unlike CVS, Subversion remembers that a file remains in conflict, and requires definite action from the user to undo this state before it will allow the item to be committed again. • Solutions to resolve • Hand-merge the conflicted text • Copy one of the tmpfiles on top of your working file • Run svn revert to toss all of your changes • Once resolved, you need to tell SVN that the conflict has been resolve • Run svn resolve • This deletes the tmp files

35. Log Messages • Log messages are not embedded in files, like CVS • Messages are associated with a single commit • Possible to change log message after commit • View log messages with svn log command

36. For More Information • Subversion home • http://svn.subversion.com/ • Subversion handbook • http://subversion.tigris.org/files/documents/15/576/svn-handbook.html • Subversion quick reference guide • http://subversion.tigris.org/files/documents/15/177/foo.ps • Subversion document folder • http://subversion.tigris.org/servlets/ProjectDocumentList • Subversion project status • http://subversion.tigris.org/project_status.html • Subversion source code and binary downloads • http://subversion.tigris.org/servlets/ProjectDocumentList

37. Thanks To • Blair Zajac who wrote part of this document • The Subversion development team who built a great tool