1 / 21

Subversion

Subversion. Kate Hedstrom April 2007. Version Control Software. System for managing source files For groups of people working on the same code When you need to get back last week’s version In the old days, there was SCCS and RCS for file-wise management Then came CVS

Download Presentation

Subversion

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. Subversion Kate Hedstrom April 2007

  2. Version Control Software • System for managing source files • For groups of people working on the same code • When you need to get back last week’s version • In the old days, there was SCCS and RCS for file-wise management • Then came CVS • Works with whole directory trees • Has a network option for remote access • Newest is SVN, which attempts to fix the shortcomings in CVS

  3. Getting Started With SVN • Tell it where the archive is with a URL: • Mine is in nanook’s /archive, visible to Sun and iceflyer • For a new archive: file:///local/path or http://host/path % svnadmin create /local/path

  4. Main svn commands • import - bring sources into the repository • checkout - get sources out of the repository • commit - check in changes • update - get changes from repository • status - find out which files would change on commit • diff - find out what changed • help

  5. Example • The svn people advise setting up a directory tree with subdirectories • trunk • tags • branches • Your actual code goes in trunk

  6. % ls /tmp/cpp branches tags trunk # import whole directory % svn import /tmp/cpp \ file:///local/path -m “initial import” % rm -rf /tmp/cpp # want to be working in checked-out copy % svn checkout \ file:///local/path/cpp/trunk cpp % cd cpp [make some changes] % svn commit

  7. Coordination # on iceflyer % svn checkout <URL> roms % cd roms [make some changes] % svn commit # on cygnus % svn checkout … % cd roms % svn update % make • Coordinate code on multiple systems • Coordinate between multiple programmers • Can be common version or different branches

  8. Updates • An update when two people have changed things can involve: • No conflict because changes are in different places • Conflict because two different changes to the same region in the code • If there is a conflict this must be resolved by human intervention • One option is to revert (undo)

  9. Other svn commands • add - add a new file or directory to svn control • delete - no longer need a file • move - rename a file or move to new location • merge - merge changes from another branch • info - find URL used • copy - make branches and tags • switch - switch working directory to a different branch

  10. Revision Numbers • svn uses a database to store the files • The whole project as one revision number across the whole project to describe that snapshot • Can see the numbers with “svn log” • This is different from CVS, which keeps a different number for each file (uses filewise RCS for repository) • Every commit creates a new revision number

  11. Branch can be just for one or a few files or the whole ROMS tree Branches

  12. Tags • Tags are handled like branches • Create a working version that goes together and make a branch in the tags directory with the name of the tag (release_1.0, say)

  13. ROMS Example • ROMS comes from a read-only repository: svn checkout <URL> hernan_roms • Make own repository where that version is the trunk • Copy it to another location without the .svn files • Import it into your repository

  14. Now make a branch for your version: svn copy <URL1> <URL2> These have to be in the same repository It is currently a copy of the main ROMS code - edit it with your changes and check it back in svn checkout <URL2> Edit… svn commit

  15. So, Hernan has made some changes, what now? Go to your copy of his code from his repository: svn update Make note of files that were added and deleted Copy to the trunk part of your repository: tar cvf - --exclude .svn | (cd ../roms_trunk; tar xvf -)

  16. In your trunk directory, add and delete the files you noted before: svn add new files… svn delete old files… Check status, then check in: svn status svn commit Make note of the version number

  17. Doing the actual merge - in the directory for your branch (URL2): svn merge -r 41:45 <URL1> Resolve conflicts, if any Check in the update, making note of the revision numbers and <URL1> svn ci -m “merge from -r 41:45 <URL1>”

  18. ROMS Summary • Each directory has .svn files pointing to its URL

  19. Conflicts • If there is a conflict, svn will provide you with four files: • The original file (filename.mine) • The older file from the trunk (filename.r41) • The newer file from the trunk (filename.r45) • A merge attempt (filename) • The merge failures will look something like:

  20. Clean code before <<<<<<< .mine My code ======= New code >>>>>>> .r45 Clean code after Once you’ve cleaned up the mess, tell svn you’re ready: svn resolved filename This will cause svn to delete the extra files and allow a commit to take place You can instead toss your changes with: svn revert filename

  21. Learn more • Version Control with Subversion, by Collins-Sussman et al., 2004, O’Reilly • Online at http:svnbook.red-bean.com/ • svn help

More Related