1 / 33

Source Code Control with Subversion CPS5401 19 Sep 2013 Umayanganie Munipala

Source Code Control with Subversion CPS5401 19 Sep 2013 Umayanganie Munipala. What is Version Control Good For?. If you work in a team, it is the best way to synchronize your work with your colleagues. It is also a way to document what changes were made, by whom, and why.

olisa
Download Presentation

Source Code Control with Subversion CPS5401 19 Sep 2013 Umayanganie Munipala

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Source Code Controlwith SubversionCPS5401 19 Sep 2013 Umayanganie Munipala

  2. What is Version Control Good For? • If you work in a team, it is the best way to synchronize your work with your colleagues. It is also a way to document what changes were made, by whom, and why. • Roll back a defective code to a version that worked. CPS5401 19 September 2013

  3. What is Version Control Good For? • Maintain project/file history • Branches allow you to have customizations that need to be kept out of the main development line. If you are working in a team, a branch is a way to develop a major feature, stay up to date with changes your colleagues make, and only add your feature to the main development • Managing releases - so you know what files are in what version CPS5401 19 September 2013

  4. What is Version Control Good For? • Even If you work alone, it is an easy way to synchronize between more than one machine. (You could even imagine traveling without all your files, and installing them from the repository onto a borrowed machine as the need arises.) • Having a source code repository is one way to backup your work. CPS5401 19 September 2013

  5. Concepts: Repository copy and Working copy CPS5401 19 September 2013

  6. Version Control Systems • Version control system keeps track of all work and all changes in a set of files, typically the implementation of a software project, and allows several (potentially widely-separated) developers to collaborate. • Classification and examples: • Distributed model - each developer works directly with their own local repository, and changes are shared between repositories as a separate step • Open-source: GNU arch, Bazaar • Proprietary: BitKeeper, Code co-op, TeamWare • Client-server model - developers use a shared single repository • Local only: Revision Control System (RCS) • Open-source:CVS, CVSNT, OpenCVS, Subversion, Vesta • Proprietary: a lot CPS5401 19 September 2013

  7. Subversion (SVN) • Directory versioning • Atomic commits • File and directory metadata • Faster network access • Requires less network access • Branching and tagging are cheap CPS5401 19 September 2013

  8. Fundamental Concepts and How it Works • Subversion is a centralized system for sharing information • At its core is a repository, which is a central store of data • Can be accessed via a HTTP or HTTPS connection • Repository remembers every change ever written to it: every change toevery file, and even changes to the directory tree itself, such as the addition, deletion, and rearrangementof files and directories. CPS5401 19 September 2013

  9. Fundamental Concepts – Working Copy & Remote copy • A Subversion working copy is an ordinary directory tree on local system, containing a collection of files • Subversion provides commands to commit your changes and merge other people changes into your working copy • Each working directory has a .svn directory (administrative directory) • Repository password are stored in each .svn folder • Stores a original copy of each file in directory CPS5401 19 September 2013

  10. Basic Subversion Work Flow • Get a working copy • Make changes in your copy • Test them locally • Integrate them with any changes made to the Repository • Commit them back to the Repository • Repeat these steps until a release is ready • Tag the release • Start making changes again for next release CPS5401 19 September 2013

  11. How to start • Subversion client is distributed as command-line tool and can be downloaded at: http://subversion.tigris.org • Tortoise SVN, a Subversion client, implemented as a windows shell extension: http://tortoisesvn.tigris.org/ • For development more convenient is to use Subclipse plug-in for Eclipse/Netbeans. Subclipse can be installed and updated from within : http://subclipse.tigris.org/install.html CPS5401 19 September 2013

  12. Netbeans SVN URL of server that hosts svn Your username and Password on that server CPS5401 19 September 2013

  13. Netbeans SVN Directory on server Side to check out (blank for whole Repository) Directory to place The files on your host CPS5401 19 September 2013

  14. Eclipse: Create repository location In Eclipse switch to “SVN Repository Exploring” perspective and create new Repository Location: • Type repository URL, e.g. • http://java-eim.googlecode.com/svn/trunk/ CPS5401 19 September 2013

  15. Check-out the project A check-out creates a local working copy from the repository. • Right-click on a module for check-out, choose “Checkout…” option • Choose to check-out using e.g. New Project Wizard • Check-out e.g. as General  Project CPS5401 19 September 2013

  16. Make changes and commit A commit (check-in) occurs when a copy of the changesmade to the working copy is written or merged into the repository. • Switch to another perspective, for example, “Java” • View and modify files in your working copy • When finished and ready to commit certainly(!!!) synchronize with repository, to avoid conflicting changes (probably somebody already modified the same files)!!! Right click  Team…  Synchronize with Repository CPS5401 19 September 2013 • To compare local and remote files double click on file

  17. Resolving Conflicts • Once in a while, you will get a conflict when you update your files from the repository • Subversion places conflict markers—special strings of text which delimit the “sides” of the conflict - into the file to demonstrate the overlapping areas • For every conflicted file Subversion places three additional files in directory: • filename.ext.mine- your file as it existed in your working copy before you updated your working copy - without conflict markers. This file has your latest changes in it. • filename.ext.rOLDREV - the file that was the BASE revision before you updated your working copy. It is the file that you checked out before you made your latest edits. • filename.ext.rNEWREV - the file that your Subversion client just received from the server when you updated your working copy. This file corresponds to the HEAD revision of the repository. • Manually resolve a conflict, execute resolved command, commit <<<<<<< filename your changes ======= code merged from repository >>>>>>> revision CPS5401 19 September 2013

  18. More Concepts and Features • Revisions • Tagging and branching • Metadata (properties) • Locking • Lock is a piece of metadata which grants exclusive access to one user to change a file • History of changes [Team  Show History] • Compare different revisions • Select two versions from history  Compare • Directories are versioned items • Deletes and moves are recorded • Copy sources are remembered CPS5401 19 September 2013

  19. Revisions • Each time the repository accepts a commit, this creates a new state of the file system tree, called a revision. • Revision numbers are global, rather than per-file • Allows to talk about “revision 2524” • Unique identifier for a state of project • Simple way to tag (next slide) • Each revision corresponds to a single commit • Contains author, log message, and date CPS5401 19 September 2013

  20. Branches and Tags • Branch - a line of development that exists independently of another line, yet still shares a common history if you look far enough back in time. • Subversion implements “cheap copies” – branches are simply copies of the main trunk • Tag is just a “snapshot” of a project in time. • Tags are copies which are never changed • Might not even be necessary if you simply record the global revision number that built your product CPS5401 19 September 2013

  21. Metadata • Any file or directory can store properties • Properties are name/value pairs • Some standard properties exist • svn:ignore • svn:mime-type • svn:eol-style • etc. • User-defined properties are allowed • Property values can be text or binary CPS5401 19 September 2013

  22. Subversion Hosting • When you decided to use Subversion in your project, then you will need a server where to place your code • Our research group server is here: • http://repository.cs.utep.edu/svn/hpcs • List of sites that offer Subversion hosting: http://subversion.tigris.org/links.html#hosting CPS5401 19 September 2013

  23. Clients for other OS users • RapidSVN is a tortoisesvn like client program that is available in Ubuntu Software Center • Mac : svnx • Centos/ Redhat (griffin) : collab.net client • $ yum install subversion • $ yum install mod_dav_svn CPS5401 19 September 2013

  24. References • Subversion home • http://svn.subversion.com/ • Book “Version Control with Subversion”http://svnbook.red-bean.com/ • Svn location for class • http://repository.cs.utep.edu/svn/cps5401/ • Username : cps5401groupX • Password : cps5401gX CPS5401 19 September 2013

  25. Exercises • svn info • URL of the repository and the revision number • Make sure it’s the working directory • svn co • svn add • svn status • svn commit –m “xxx” • svn update CPS5401 19 September 2013

  26. Exercises (conflicts) • how do deal with conflicting edits by two users of the same repository.? • %% emacs firstfile # make some change • %% svn commit -m "another edit to the first file" • Sending firstfile • svn: Commit failed (details follow): • svn: Out of date: ’firstfile’ in transaction ’5-1’ CPS5401 19 September 2013

  27. Exercises (conflicts) • The solution is to get the other edit, and commit again. After the update, svn reports that it has resolved a conflict successfully. • %% svn update • G firstfile • Updated to revision 5. • %% svn commit -m "another edit to the first file" • Sending firstfile • Transmitting file data . • Committed revision 6. • G at the start of the line indicates that svn has resolved a conflicting edit. CPS5401 19 September 2013

  28. Exercises (conflicts) • If both students make edits on the same part of the file, svn can no longer resolve the conflicts. If both students make edits on the same part of the file, svn can no longer resolve the conflicts. • %% svn commit -m "another edit to the first file" • svn: Commit failed (details follow): • type e to open the file in an editor • Or type p for ‘postpone’ and edit it later. • After editing and resolving conflict commit the file • %% svn resolved firstfile • Resolved conflicted state of ’firstfile’ • %% svn commit -m "another edit to the first file" CPS5401 19 September 2013

  29. Conflict Options • (e) edit - change merged file in an editor • (df) diff-full - show all changes made to merged file • (r) resolved - accept merged version of file • (dc) display-conflict - show all conflicts (ignoring merged version) • (mc) mine-conflict - accept my version for all conflicts (same) • (tc) theirs-conflict - accept their version for all conflicts (same) • (mf) mine-full - accept my version of entire file (even non-conflicts) • (tf) theirs-full - accept their version of entire file (same) • (p) postpone - mark the conflict to be resolved later • (l) launch - launch external tool to resolve conflict • (s) show all - show this list CPS5401 19 September 2013

  30. History: How to get information about the repository. • svn info • svn log • svn log 2:5 • svn diff • To see differences in various revisions of individual files • First Update the svn • svn diff firstfile CPS5401 19 September 2013

  31. Exercises (Shuffling files around) • svn mkdir trunk • See the output • Create a file somefile and commit it to the repository. Then do rm somefile • svn status • svn revert • deleted : brought back from repositary • undo any local edits • svn --force rm yourfile. CPS5401 19 September 2013

  32. Exercises(Branching and merging) • svn copy \<the URL of your repository>/trunk \<the URL of your repository>/onebranch \ -m "create a branch“ • This is not visible in the trunk. Checkout and see. Edits are also not visible svn co <the URL of your repository>/onebranch \projectbranch • edits in the main trunk can be pulled into this branch: • svn merge ˆ/trunk --- Merging r13 thro r15 into ’.’: CPS5401 19 September 2013

  33. Exercises(Branching and merging) • When you are done editing, the branch edits can be added back to the trunk. • svn co file://‘pwd‘/repository/trunk mycleanproject • A # all the current files and then do a special merge: • cd mycleanproject • svn merge --reintegrate ˆ/branch CPS5401 19 September 2013

More Related