SVN

1. Subversion is a centralized version control system
2. Version Control System: system that are designed to track changes to data overtime
3. Core mission: enable collaborative editing and sharing of data
4. drawbacks of lock-modify-unlock:

• • cause administrative problems: one forget to unlock the file
  • cause unnecessary serialization: two people's work won't overlap
  • create a false sense of security: two people editing different files that relate to each other

1. Copy-Modify-Merge
2. Subversion is primarily a copy-modify-merge system, it still has locking feature.
3. Subversion URLs: Subversion uses URLs to identify versioned files and directories in Subversion repository. Subversion's files exist in a virtual filesystem(different from the browser's understanding). URLs which have spaces must be enclosed in quotes. Caret (^) notation was introduced as a shorthand for “the URL of the repository's root directory”: 

   $ svn list ^/tags/bigsandwich/  // Note that this URL syntax only works when your current working directory is a working copy—the commandline client knows the repository's root URL by looking at the working copy's metadata. 

4. 
5. Each directory in your working copy contains a subdirectory named .svn, known as the working copy's administrative directory. A typical Subversion repository often holds the files for several projects, a user's working copy will usually correspond to a paticular subtree of repository.
6. A repository's file system(two projects: calc and paint):
7. 
8. Commit and Check out:
   • Check out: create a private copy of the project: 

     $ svn checkout http://svn.example.com/repos/calc
     A    calc/Makefile
     A    calc/integer.c
     A    calc/button.c
     Checked out revision 56.
     $ ls -A calc
     Makefile  button.c integer.c .svn/              //.svn contains meta data that Subversion maintains

   • Commit: publish your changes(or checking in)

     $ svn commit button.c -m "Fixed a typo in button.c."
     Sending        button.c
     Transmitting file data .
     Committed revision 57.

   • Update: update working copy:

     $ pwd
     /home/sally/calc
     $ ls -A
     Makefile button.c integer.c .svn/
     $ svn update
     U    button.c
     Updated to revision 57.

9. Revision: each time the repository accepts a commit, this create a new state of the file system tree, called a revision. The initial revision of a freshly created repository is 0 and consists of nothing but an empty root directory.
10. 
11. Subversion records two essential information in the .svn/ administrative area:
    • the file's working revision
    • A timestamp recording when the local copy was last updated by the repository
12. Upgrades and Commits are seperate
13. Usage: svn help(command to help)
14. Recommended layout: 

    $ svn list file:///var/svn/repos
    /trunk                           /* hold the main line of development *//branches                        /* contain branch copies *//tags                            /* contain tag copies */

15. Specifying a revision:
    • HEAD:  the most recent revision
    • BASE:  the revision of an item that you have in your working copy 
    • COMMITTED:  the revision in which the item was last changed
    • PREV:  the revision before the the item was last changed
16. 
17. Create repository:

    $ svnadmin create myrepos
    $ ls -l myrepos/

Initial layout(single project, top-level):
• /trunk: hold the main copy of the project where most development occurs 
• /branches: hold separate lines of development (remember, those will just be copies of /trunk) 
• /tags: hold copies of the project as it exists at significant points of time, such as a release 
18. On Unix systems, it is usually a great time-saver to use shell variables to store repo URLs, rather than retyping them everywhere. 
19. import: 

    $ svn import my-project file:///path/to/repository/trunk 
                 -m "importing my project"

20. Get info of your working copy: 

    $ svn info  // enables you to find information about items in your work- ing copy 

    $ svn status    // It prints out the current status of your working copy, When you run just svn status, with no arguments, it will tell you only about files and directories in your working copy that you’ve modified 

    $ svn status -v // verbose mode, 

21. As you already know what has changed, run svn diff to see exactly what.
    • svn status -u: tells svn status to contact the repository and figure out what files have been changed in more recent revisions 
    • svn diff -r BASE:HEAD: see difference between BASE revision and HEAD
    • svn log -r BASE:HEAD: read the log messages
22. Conflicts: 

    $ svn resolved bar.c // resolve a conflict file bar.c
    $ svn commit --file svn-commit.tmp

23. Manage file:

    $ svn copy FROM TO
    $ svn move FROM TO
    $ svn mkdir DirName // DirName not exist
    $ svn add DirName  // DirName exist not under Subversion's control
    $ svn delete PATH

24. Tags and Branches: 
    • Subversion create tags and branches in constant time and space as opposed to in time and space proportional to the number of files involved, as in CVS
    • Branches and Tags are copies of existing directories, usually placed in special directories
    • Make a tag when you release a new version of your project
    • Edit a branch to be safe with trunk project
25. Subversion uses repository UUIDs to distinguish repositories
26. '^/' : Repository root URL
27. Sometimes binary files cannot be merged properly, so you need lock the file:

    $ svn lock unmergable.bin –message “Working on drawing for the next hour”

    The user who locked the file can unlock it by committing or by an explicit svn unlock command:

    $ svn unlock unmergable.bin

28. To break a lock: 

    $ svn unlock -force http://example/repos/trunk/unmergable.bin

    the URL to the file must be provided

29. Properties(meta data):
    • What properties have been set on a perticular versioned resource: svn proplist
    • svn reserves all properties starting with prefix svn: with it self
    • svn propget: prints out the value of a given property for you 

      $ svn propget svn:mime-type index.html             // 2 arguments: 1st, the property name, 2nd, file name

    • svn propset; svn propedit:

      $ svn propset svn:mime-type image/png logo.png    // property name, property value, file name

30. Subversion's properties:
    • svn:mime-type: tells subversion what mime type a file is
    • svn:ignore: files in working copy that don't want to be checked in to Subversion. you can simply add an entry to the directory’s svn: ignore property that matches their filenames, and svn status will ignore them, unless you pass it the --no-ignore option 

      $ svn propset svn:ignore "*~" .

    • svn:need-lock: When this property is set on a file it will be read-only until svn lock is called on the file, It is a recommended practice to set this property on any file that cannot be merged contextually. 
    • svn:keywords: HeadURL, LastChangeBy(Auther), LastChangeDate(Date), LastChangeRevision(Rev), Id
31. Subversion won’t allow you to change revision properties unless you explicitly turn this capability on. To turn on this capability, you look up hooks dir in repos, and there is a file named "pre-revprop-change.tmpl", copy it and make it executable using "chmod -x pre-revprop-chang". pre-revprop-change.tmpl will let you change only the svn:log revprop.
32. svn blame: svn blame takes a working copy path or URL and optionally a range of revisions, and outputs a formatted version of the file in which each line is prefixed with the revision that line originates from and the username of the author of that revision:

    $ svn blame file:///Users/usrname/svn/repos/trunk/index.html  //svn blame is meaningless when applied to a directory or to a binary file. 

33. svn cleanup: svn cleanup just takes the path to your working copy as an argu- ment (or uses the current working directory if you don’t give it one) and runs through the working copy, finishing up all unfinished work and removing stray locks. Note that you should run svn cleanup only on a working copy that isn’t being accessed by another Subversion client
34. svn export: You can think of it as an svn checkout that doesn’t write out the administrative directories: 
    the directory you export to isn’t a working copy—it has no administrative .svn directory:

    $ svn export file:///path/to/repository/tags/release-1.0 release-1.0

35. Common multiple projects layout:
36. 
37. n
38. n
39. n
40. n
41. n
42. n
43. n
44. n