Subversion

From Alessandro's Wiki
Jump to: navigation, search

installation

gpasswd -a apache svnusers
gpasswd -a xunil svnusers
chown -R apache:svnusers /md5/subversion/videoteca
chmod -R g-w /md5/subversion/videoteca
chmod -R g+rw /md5/subversion/videoteca/db/
chmod -R g+rw /md5/subversion/videoteca/locks/
  • authentication for the client:
~/.subversion/config
[auth]
password-stores = kwallet
  • do not store passwords:

Add the following in ~/.subversion/servers, under the [global] section:

store-passwords = no

To not store only plain text password instead add:

store-plaintext-passwords = no

Usage

  • ignore files/ directories
svn propedit svn:ignore thefile
  • url of a working copy
svn info | grep URL
  • change, switch, modify the path of a working copy
svn switch svn://newurl
  • adding a file containig "2" in its filename.
    • just put another @ at the end (end end) of the name string:
$ svn add 'aaa@bbb'
svn: warning: 'aaa' not found
  • then...
$ svn add aaa@bbb@
A         aaa@bbb
svn switch --relocate
svnadmin setuuid <repository path> <new uuid>


QuickStart (tm)

Summary

  • svn import: add a location to the repository
  • svn checkout: copy to a location from the repository
  • svn update: brings your working copy up-to-date with the repository.
  • svn diff: output the differences between your changes and the last update.
  • svn status: show the status of your changes. This command should systematically be used before committing.
  • svn commit: commits the new version of your files to the repository.
  • svn revert: revert your changes to the last update.

So you were just on $SERVER and imported your code into svn. Now let's pretend you're on $REMOTE and you want create the same directory structure as your original as well as checkout a copy of the code you just imported.

cd $HOME
mkdir Documents/code/$PROJECT_1 -p
svn checkout svn+ssh://$USER@$SERVER/$HOME/my-repository/$PROJECT_1 Documents/code/$PROJECT_1

Then you make some changes and you want to check what the changes were exactly and the status, where you find that one file has changed and one file has been added, and one deleted. This is what you expect so you commit the updates to $SERVER.

cd $HOME
mkdir Documents/code/$PROJECT_1 -p
svn diff Documents/code/$PROJECT_1
svn status Documents/code/$PROJECT_1
   #?      Documents/code/${PROJECT_1}/trunk/ultra-crunch.c
   #M      Documents/code/${PROJECT_1}/trunk/super-crunch.c
   #!      Documents/code/${PROJECT_1}/trunk/old-crunch.c
svn commit Documents/code/$PROJECT_1
   # make a comment about your submittion
   #Sending        Documents/code/${PROJECT_1}/trunk/ultra-crunch.c
   #Transmitting file data .
   #Committed revision 2.

You get back to your original machine late tonight and want to update with the files you submitted earlier, but then you decide that you mustn't have had your coffee yet when you had submitted those changes earlier because they are terrible. (and so is this joke, but then again, I haven't had my coffee yet either!)

cd $HOME
mkdir Documents/code/$PROJECT_1 -p
svn update Documents/code/$PROJECT_1
   #At revision 2.
svn revert Documents/code/$PROJECT_1
  • command list
   add
   blame (praise, annotate, ann)
   cat
   changelist (cl)
   checkout (co)
   cleanup
   commit (ci)
   copy (cp)
   delete (del, remove, rm)
   diff (di)
   export
   help (?, h)
   import
   info
   list (ls)
   lock
   log
   merge
   mergeinfo
   mkdir
   move (mv, rename, ren)
   propdel (pdel, pd)
   propedit (pedit, pe)
   propget (pget, pg)
   proplist (plist, pl)
   propset (pset, ps)
   resolve
   resolved
   revert
   status (stat, st)
   switch (sw)
   unlock
   update (up)

SVN structure template

  • project
    • branches
    • tags
    • trunk
  1. branches hold copies of the source that are being actively worked on or maintained but require separation. For example the code for v4 might be inside a branch to allow people to work on future changes that won't be implemented for a while. This allows them to do their work without prematurely placing code in the trunk. These branches are often called "project branches".
  2. tags hold copies of the software at various milestones, like v1, v2, v3.
  3. trunk is used to hold the most up to date stable version of your software.