Finding versions of the Abjad toolchain

Use the following commands to find versions of Abjad tools:

$ lilypond --version
GNU LilyPond 2.15.3 ...

$ python --version
Python 2.6.1

$ py.test --version
This is py.test version 2.1.0 ...

$ sphinx-build --version
Sphinx v1.0.7 ...

$ less `which easy_install`
... __requires__ = 'setuptools==0.6c9' ...

$ svn --version
svn, version 1.6.17 ...

Upgrading the OS X Subversion client

1. Check your current version of the Subversion client with svn --version.

2. Check Apache to find the most recent version of the Subversion client. You do *not* want alpha or beta versions of the Subversion client. You want the most recent stable version of the Subversion client.

3. Download the OS X binaries from CollabNet and double-click the installer after download. You will need to supply CollabNet with a name and email address to download.

4. Check your current version of the Subversion client again with svn --version. If the client has updated then you're done. If the client appears not to have updated then make sure that /usr/local/bin appears early on your PATH.

OS X Subversion config file

The Subversion config file is kept at ...

  ~/.subversion/config

... under OS X.

Setting svn:ignore on __pycache__ directories

py.test 2.1 introduces the use of __pycache__ directories.

Use ...

  svn propset -R svn:ignore __pycache__ directory

... to ignore ___pycache__ directories in directory and in all subdirectories of directory.

The property setting will be committed to the repository on your next check-in and will thereafter be acquired by all other users of the repository on check-out.

Using a repository from the beginning

Sometimes you realize that a project will require the type of versioned content and remote access charateristic of a repository only after the project has been running for some weeks or months. Other times it may clear from inception that a repository will be required. If you know your project will require a repository from the beginning, then you can set everything up quite cleanly.

1. Set up your project repository on the remote server.

2. Check out a copy of the newly created, empty repository.

That's it. You can now add content to your local working copy and commit as usual.

Which svn files changed?

Using svn log --limit 1 or svn log --limit 2 gives log messages for the last one or two commits.

Show which files changed with -v.

manifolds$ svn log --limit 1 -v
------------------------------------------------------------------------
r251 | tbaca | 2009-07-06 08:51:13 -0500 (Mon, 06 Jul 2009) | 1 line
Changed paths:
   A /manifolds/color/aa_layer_staves_on_blocks
   A /manifolds/color/aa_layer_staves_on_blocks/helpers
   A /manifolds/color/aa_layer_staves_on_blocks/helpers/__init__.py
   D /manifolds/color/layer_staves_on_blocks.py

Layer staves on blocks.
------------------------------------------------------------------------

Finding parent repository IP address

Running svn info provides parent repository IP address.

manifolds$ svn info
Path: .
URL: svn://128.129.130.22/manifolds/manifolds
Repository Root: svn://128.129.130.22/manifolds
Repository UUID: 6f904fc4-c55a-0020-9830-e67326506173
Revision: 16
Node Kind: directory
Schedule: normal
Last Changed Author: tbaca
Last Changed Rev: 16

Useful to save an IP address lookup.

Setting up a new Subversion score repository

On the remote server:

   $ svnadmin create foo

The foo repository now exists and contains the following:

   $ ls foo
   conf  dav  db  format  hooks  locks  README.txt

Access privileges must now be assigned:

   $ vi foo/conf/svnserve.conf

And then:

   anon-access = none
   auth-access = write
   password-db = passwd

And then:

   $ vi foo/conf/passwd

And then:

   [users]
   tbaca = password

Initial check-in is now possible.

Renaming an SVN repository and using --relocate

Consider the difference between, on the one hand, an actual SVN repository and, on the other, a mere working copy of that repository. With that distinction in mind, it might sometimes be desirable to change the name of the actual SVN repository. The Subversion Book in the section on moving and removing repositories makes clear that you need use only UNIX mv to do this.

   mv repos newnamerepos

But this is only half the story. Any working copies that 'point' to this repository formerly known as repos but now known as newnamerepos will now be 'orphaned' and no longer know how to communicate with the repository.

The answer is in Subversion Book under the section on svn switch. The answer is the --relocate option.

   svn switch --relocate svn://128.129.130.22/repos \
      svn://128.129.130.22/newnamerepos

Make sure to specify only the URL part of the path to repository.

Seeing SVN global ignores

The output of

   svn status

will, by default, hide files with names matching the patterns added to global-ignores or set with svn propset svn:ignore, which is a good thing.

But if you're migrating an entire repository, it might be helpful to see everything that Subversion sees, including those files which Subversion ignores. If so, use

   svn status --no-ignore

instead.

One-line check-out

To check out a remote SVN repository in a single line, use ...

   svn co --username username --password password svn://128.129.130.22/repos

... and note the availability of the --username and --password options to svn co.

Moving an entire SVN repository to a public server

Suppose you have an SVN repository on a workstation at home. And suppose your home workstation does not act as a server on the public internet. It may eventually come time to move the entire SVN repository from your home workstation to a server that is on the public internet. Here's how.

The Subversion Book chapter on moving and removing repositories says the following:

Subversion repository data is wholly contained within the repository directory. As such, you can move a Subversion repository to some other location on disk, rename a repository, copy a repository, or delete a repository altogether using the tools provided by your operating system for manipulating directories—mv, cp -a, and rm -r on Unix platforms ...

You might at first think this means that UNIX scp will be enough to move an entire SVN repository from your home workstation to a server on the public internet. But this is not the case.

Enter svnadmin dump and svnadmin load.

On your home workstation, change to you svn directory and find the repository that you want to move. Make sure you find the repository and not merely a working copy of the repository:

   $ cd /var/svn

Redirect the stdout from svnadmin dump to create a dumpfile:

   $ svnadmin dump my_repository > my_repository_dumpfile

Copy the dumpfile to the remote server:

   $ scp my_repository_dumpfile tbaca@128.129.130.22:/home/tbaca/svn

Log in to the remote server:

   $ ssh -l tbaca 128.129.130.22

Switch to the appropriate directory on the remote server:

   $ cd /home/tbaca/svn

Create the new repository, if it does not yet already exist:

   $ svnadmin create my_repository

Load the dumpfile into the new repository, directing from stdin:

   $ svnadmin load my_repository < my_repository_dumpfile

Done.

A new Subversion repository

Create an new, empty repository.

   /$ svnadmin create /svn/lidercfeny

Import existing files.

   /$ cd /Users/trevorbaca/Documents/music
   music$ svn import lidercfeny file:///svn/lidercfeny -m "Initial import"

Replace unversioned files with versioned files.

   music$ rm -r lidercfeny
   music$ svn checkout file:///svn/lidercfeny

Subversion quick reference

To get HELP on subversion:

1. svn help <command>

2. the svn manual is at http://svnbook.red-bean.com/

To REVERT uncommitted changes inside a branch:

1. cp <file> to another location as a precaution
   
2. svn revert <file> or svn revert -R to recursively revert all files

To RESOLVE merge conflicts:

1. svn status to display C€ in first column for conflicted files
   
2. manually fix each file and replace old binary files with new ones
   
3. type svn resolved <file>€ for each file or type svn -R resolved€ to resolve all files recursively
   
4. svn commit

To CREATE <branch>:

1. svn copy svn://svn/<repository>/trunk svn://svn//branches/<branch>
   
2. <branch> creates within the repository and does not create locally
   
3. auto-commit will follow

To CREATE <new branch> from <old branch>:

1. svn copy svn://svn/<repository>/branches/<old branch> svn://svn/<repository>/branches/<new branch>
   
2. <branch> creates within the repository and does not create locally
   
3. auto-commit will follow

to DELETE <branch>:

1. svn delete svn://svn/<repository>/branches/<branch>
   
2. <branch> removes within the repository; careful!
   
3. auto-commit will follow

To MERGE <branch> to <trunk>:

1. cd to local copy of <branch>
   
2. get the rev. number where the branch was created, or where it was last merged: svn log --stop-on-copy
   
3. cd to local copy of <trunk>
   
4. make sure it's the latest & greatest: svn update
   
5. do the actual merge; plug in <rev> and <branch>: svn merge -r <rev>:HEAD svn://svn/<repository>/branches/<branch>
   
6. resolve conflicts
   
7. svn commit

To MERGE from <trunk> to <branch>

1. cd to local copy of <branch>
   
2. get the rev. number where <branch> was created: svn log --stop-on-copy

3. svn merge -r <rev>:HEAD svn://svn/<repository>/trunk <branch>

4. resolve conflicts

5. svn commit

To MERGE from <new branch> to <old branch>

1. cd to local copy of <old branch>
   
2. get the rev. number where the old branch was created: svn log --stop-on-copy
   
3. cd to local copy of <new branch>
   
4. svn merge -r <rev>:HEAD svn://svn/<repository>/branches/<old branch>

5. resolve conflicts

6. svn commit

Bill authored this last week for the guys at work.