Changes between Initial Version and Version 1 of CaffeinatedSubversion

01/18/11 12:23:08 (12 years ago)



  • CaffeinatedSubversion

    v1 v1  
     1This page is intended to explain enough about Subversion to work with the Debathena repository.  For more information on Subversion, see O'Reillys "Version Control with Subversion", available at [], or though the MIT Libraries' subscription to [ Safari (Touchstone authentication required)] 
     3==Getting started== 
     5Normally, you would use the Subversion URL `svn+ssh://` to work with Subversion.  However, this requires write access to the repository.  If you don't have write access, you'll only be able to check out the code, not commit anything, and you'd use the URL `svn://` instead. 
     7Changes in subversion are identified with revision numbers (e.g. r12345).  This revision number applies to the entire repository, even though the actual change likely only affected a few files. 
     9==Initial checkout== 
     11Identify a location in your filesystem for your working copy of the source, and change to that directory.  Then, checkout the source with the following command: 
     12`svn co svn+ssh:// athena`. 
     14This will create a directory called `athena` in the current directory, with the Athena source tree inside that directory.  That directory is called a *working copy*.   
     16==Getting an update from the server== 
     18Before making changes, you'll want to ensure you have the latest copy of the code.  `svn update` will get you the latest copy of the code.   
     21joeuser@athena:~$ svn update 
     22A foo.c 
     23U bar.c 
     24D baz.c 
     27In this example, foo.c is a new file, bar.c was changed ("updated"), and baz.c was deleted.  It's possible you'll encounter conflicts at some point, but that will be covered later. 
     29==Making changes== 
     31Most text editors are aware of when you're editing files inside a working copy.  Emacs, for example, won't create "twiddle files" (`filename~`) because it assumes Subversion will keep track of your changes. 
     33===Adding or removing files=== 
     35If you create new files or directories, you'll need to ensure Subversion is aware of them.  You can wait until just prior to the commit to do this, or you can do it as you go.   To add files or directories use `svn add`: 
     37`svn add` 
     38`svn add *.c` 
     39`svn add subdir` 
     41To remove files previously added, use `svn del`: 
     43`svn dell` 
     44`svn del *.c` 
     45`svn del subdir` 
     47==Reviewing your changes== 
     49To view information about what files have been changed, use `svn status`.  By default, it will display status on the current location in the repository, or you can specify a directory or file, or with no arguments 
     51*Tip:* Make sure you're in the right directory when you run this command.  For example, if you're working on package `foo`, but you're actually in `foo/bar`, it might not give an accurate listing of your changes to be committed. 
     55joeuser@athena:~$ svn status 
     56A   foo.c 
     57M   bar.c 
     58D   quux.c 
     59?   subdir 
     60!   baz.c 
     62In this example, bar.c has been changed and will be committed.  foo.c is a new file, which has been added with `svn add`, and quux.c has been deleted with `svn del`.  The directory `subdir` exists in the filesystem, but is not under version control.  If it's part of the package, you'll need to add it with `svn add`.  The file `baz.c` should exist, but doesn't.  If you delete a file with `rm`, you'll also need to `svn del` the file so Subversion knows it's gone.   Additional information about the output format of `svn status` is available in the documentation, or with `svn help status`. 
     66If you want actual diffs, you can use the `svn diff` command.  Like `svn status`, it can take optional file specifiers, or display all diffs. 
     68==Reverting changes== 
     70If you realize that you didn't want to make changes, you can revert a file's changes.  Without any arguments, `svn revert` will revert your entire working copy, and won't ask for confirmation, so use it with care. 
     72`svn revert foo.c` 
     74==Committing your Changes== 
     76Before committing, make sure your working copy is up to date with `svn update`. 
     78You commit your changes with `svn commit`.  You can specify files to commit, or by default it will commit everything in the current working directory and subdirectories.  It's best to run `svn status` ahead of time to verify what will be changed.  You'll also want to specify a commit message with "-m".  Commit messages should be descriptive, but concise.  Don't mention what files have changed, the commit log will tell other users that.  Instead, say what you actually did.  Example: 
     80`svn commit -m 'Fixed a string-handling bug in bar.c'` 
     82If you are in the root directory of a package, and have added a new Changelog entry to `debian/changelog`, you can leave the commit message blank, and the Subversion server will use the contents of the new Changelog entry as the commit message: 
     84`svn commit -m ''` 
     85^(That's two single-quotes, i.e. an empty string)^ 
     87===Reverting a commit=== 
     89If you want to revert a commit that you've already made, you can't use `svn revert`.  Instead, you need to merge the changes back in to the current working copy, and then re-commit it. 
     92You've just committed change r12345.   
     93To revert it in your working copy: `svn merge -r 12345:12344 .`   (don't forget the trailing period so Subversion knows to operate on the current working directory) 
     94This will reverse-merge the changes from 12344 (what it looked like before your commit) into the current working copy. 
     95You'll then need to commit the changes:  `svn commit -m 'Reverted r12345'`