CSC323 2010S, Class 11: Tools: Version Management with Subversion Overview: * An introduction to Subversion and source-code management. * Subversion exercises. * Beautiful Code: the delta editor. * Project stories. Admin: * EC for Thursday's Thursday Extra and Friday's CS Table. * EC for orchestra Saturday the 13th at 2pm * Reading for Thursday: Beautiful Code Chapter 3 * Skimming for Thursday: The GNU Make Manual, chapters 1-5, 10. * I will reserve time at the start of class to address the recent racial bias incident. Source Code Management Systems * What are they? (Self-evident) * What do they do? * Provides a repository that permits collaborative development * May better permit distributed access to the code * Provide an archive of past versions of software (revision control) * Sometimes big sweeping changes are the wrong thing * Sometimes small changes are the wrong thing * Sometimes we want to figure out what changes we made * We also want documentation * Most of us end up keeping multiple versions of files anyway, and this clarifies things * Why do we want them? * See above * What capabilities would you expect a SCM to have? * To be able to compare two versions + Your working version and the latest version + The latest version and the latest-1 version + Two archived versions + High-level: What files etc. have changed? + Low-level: How has each file changed? + Higher-level: Is this the most recent copy? * To be able to grab the software from the archive + Current version + Older version * Update my copy to the latest version * Insert changed file into the repository * Add files and directories * Remove files and directories * Support multiple branches - separate copies, each with its own set of individual changes + merging of branches * Revert to a previous version + "Oops, that was a bad idea." + Throw away changes * Log of changes (comments thereon) * Finalize a file - No more changes are permitted * But why? * Other characteristics you'd like * Efficient use of resources * Not too much file space * Not too much time * Not too much "programmer overhead" * Not too much bandwidth * Handle conflicts well. * Identify those who work on the document. * Easy to use * Access permissions * Many collaborative editing systems (e.g., Wikis) now contain many of these characteristics Subversion - svn * A popular open-source source-code management system * The imporant thing in using an SCM is the habits of use, rather than the particulars of the system * Good programmers can change systems relatively easily * Standard svn commands svn ACTION PARAMETERS svn help svn help action svn co archive - check out an archive svn add file - note that we want to add a file to the archive svn commit - commit any changes we have made back to the central repository + add a file or directory + delete a file or directory + modify a file svn commit files - commit a particular file svn update - grab the latest version of the repository svn log -- list the history svn log file - find a log of changes svn diff file - compare a file to the repository version * Good svn usage * Follow the standard svn directory structure * DOCUMENT EVERY COMMIT! * Commit one change at a time, provided the changes are independent * Much easier to undo a single change * Commit only working code! (Or at least compilable code.) * Always update before committing. * Begin each programming session with an update. STRETCH TIME Questions * How do you "log in" to the system? * Traditional MathLAN perspective: No account needed to access files; account needed to update * svn://svn.cs.grinnell.edu/designers Practice * Make a group of about three students and two separate logins (different accounts). + You can use multiple computers. + You can use multiple terminal windows. * Create a local repository available to both logins. * svnadmin create - create repository * Check out the repository with both logins. * Using the repository as your working copy is a bad idea! * Add a file to that repository with one account and obtain it with the other account. * Write a small Python class that has two methods, add it to the repository, and make sure that both accounts have copies. * Determine what happens if each account modifies a different part of the code (e.g., the two methods) and tries to commit the revision. * Determine what happens if each account modifies the same part of the the code (e.g., the first line of the first method) * Have one account modify the code and commit the code and ask the other to compare its current version to that in the repository. * Both create a file with the same name (and same contents) and try to add the file to the repository. * Both create a file with the same name (and different contents) and try to add the file to the repository. * Add a file to svn://svn.cs.grinnell.edu/designers/tests Notes * File repositories can be a PITA, particularly for multiple users. * Generally, we use file repositories only for our own stuff or in a system in which we have narrower group permissions. * SVN follows *nix conventions and looks for the definition of VISUAL to decide on what editor to use. If you like something other than vi (the default setting), you might want to add a line like export VISUAL=/usr/bin/emacs to your .bashrc or .bash_profile * Potential conflicts: * Different changes to the same line - Reported conflict * Delete different lines - No conflict * Insert two different lines at the same place - Reported conflict * Behavior may depend on the version of svn or particulars. * BE CAREFUL ABOUT WHAT HAPPENS ON UPDATES Hello ill student. We hope that you are feeling better. We discussed whether we should do a variant of Conway's game of life rather than iSimGrinL.