NOTE 2: I’ve noticed a lot of traffic to this page for “local edit incoming delete on update” errors, which are not what this article is about (the solution below may or may not work for that — I have no idea). This article is about “local delete, incoming delete on update” errors. Always back up your work before you muck around with something like this, but that goes doubly if you’re going to try to use these instructions for the “local edit” error.

For reason I’m still trying to untangle, I encountered some really terrible conflicts this afternoon with an SVN checkin that didn’t complete properly, leaving me with a few locked directories that wouldn’t respond to “svn cleanup”.

Using these instructions, I was able to get the directories sorted out:

1. Move offending directories out of working copy and to a safe place (e.g. desktop)
2. Run svn cleanup
3. Run svn up

This actually restored the messed-up directories. Some files were reverted and some deleted files restored; once the entire working copy is cleaned up, you can use the backup copies of the directories to copy back in your changes.

But before I could do that, I was left with a half-dozen individual file conflicts with the following messages:

$ svn st
?   C some_file.php
    > local delete, incoming delete upon update
?   C some_other_file.php
    > local delete, incoming delete upon update
... etc.

Thankfully, these were files that I did want to delete, so even without instructions I wasn’t afraid to trial-and-error my way to the following fix:

$ touch some_file.php some_other_file.php
$ svn revert some_file.php some_other_file.php

Once you’ve created the files, SVN can revert them, which leaves them in unversioned status:

$ svn st
?    some_file.php
?    some_other_file.php

And then you can just delete them from the command line or whatever file manager you use.

*Phew*

Once that was done I redid some deletions that had been overwritten by the update that cleaned up the directories, and all was right in the world.

Usual disclaimers, YMMV, etc.

1. Do Not put your repository under your Apache web root, or any virtual host web root. Just don’t. It won’t work.
2. Apache needs read and write permissions on your Subversion directory. The simplest but perhaps not the most secure way to do this is, after you create the repository, to change the owner of the repository directory and all its contents to the user that Apache runs as (in my case, www).

   If you want to still be able to write directly to it (for instance, to set up the configuration) without sudo-ing, you can change the group permissions to allow a group that you’re a member of to write to it. (Like I said, this is probably not the most secure way to do things, but it’s the easiest, and probably fine for something that’s carefully limited to your own machine. I hate dealing with file permissions, so I set it up the lazy way.)

   You can do all of this with OS X’s “Get Info”, or on the command line with chown -R and chgrp -R

3. In your repository, find conf/svnserve.conf, and uncomment the following lines:

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

4. Now open conf/passwd and add a line to the bottom with the format:

   username = password

   subtituting, of course, the username and password that you want to use to access your repository. You can add additional lines for additional users.

5. The SVNbook recommends creating trunk, branches, and tags subdirectories for each project in your repository, although this is by no means required. I don’t ancipate doing a huge amount of branching, but I figured it couldn’t hurt.

   The easiest way to get this set up, if you have already started your project somewhere and can’t change its location without breaking things because of absolute path configurations, is as follows:

   1. Create a tmp directory on your desktop.
   2. Inside tmp, create a directory with the name of your project. You’ll be happiest if this is short and doesn’t include any spaces.
   3. Inside the project directory, create trunk, branches, and tags directories.
   4. svn import . --username YOURUSERNAME --password YOURPASSWORD http://localhost:81/svn -m "repository layout for PROJECTNAME", substituting the appropriate username, password, and projectname. If you’re using a different URL for your repository, substitute that too, of course.
6. You may want Subversion to ignore particular types of files. For instance, with Django, I’m working with Python, which creates a compiled bytecode file for each script, with the extension .pyc. These don’t need to be versioned because each one is recreated automatically from the script every time you change it and run it.

   Different languages and project types will have different files to ignore. There are also OS metadata files like OS X’s .DS_Store and Windows’ Thumbs.db that you probably don’t want to carry around either.

   This is set up on the client side, and you’ll probably want to take care of it before importing or adding anything beyond that skeletal directory structure.

   Open ~/.subversion/config, and locate the [miscellany] section. In there is a line, possibly commented out, that looks something like this:

   # global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store

   Uncomment the line if it’s commented out, and add .DS_Store (if it’s not already there) and *.pyc to the end, so it looks something like this:

   global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store *.pyc

   While you’ve got the file open, you might want to scroll up to the [helpers] section, and uncomment the editor-cmd line, and set it to use your editor of choice.

7. OK, we need to import our project now.

   First, cd into the parent directory of your project directory, and check out the trunk of the project (since the trunk is empty, this will do nothing except create a .svn directory in the project directory, so subversion can handle it properly as a “working copy.):

   svn checkout http://localhost:81/svn/PROJECTNAME/trunk PROJECTDIR

   Then, cd into the project directory and tell Subversion to add everything from your project to the repository. For each subdirectory of the project that you want under version control (Subversion will recursively add directory contents):

   svn add SUBDIRNAME

   Then add the files that live in the root in the project directory that you want versioned. I had a couple files I wanted to ignore (such as my sqlite database), so I just added the Python scripts:

   svn add *.pyc

   Then commit everything:

   svn commit -m "Adding initial project files"

   And you’re done!

But besides that, CVS is really obsolete at this point, and Subversion has really taken over its status as the de facto standard for free, open-source revision control software.

Installation was yet another project that turned out to be super-easy with a little help from Darwinports.

Here’s the full set of steps to install:

1. Grab Apache 2 off Darwinports and get it running separately from the default OS X Apache 1.3 installation (PHP, MySQL, et al entirely optional). Darwinports’ Apache automatically includes mod_dav, which you’ll need.

2. Install Subversion and Apache’s dav_svn_module:

   sudo port install subversion +mod_dav_svn

   Darwinports’ Subversion conveniently includes both server and client. Spiffy.

3. Decide where your repository is going to live. I set up a directory under my user directory, with the full path /Users/myusername/svn

4. Configure Apache to work with Subversion. First, add the following to the bottom of the list of LoadModule directives in httpd.conf:

   LoadModule dav_svn_module modules/mod_dav_svn.so

   Then add the following to the end of httpd.conf:

   <Location /svn ># I think you can change "/svn" to whatever you want the path to be on your server.
DAV svn
SVNPath /Users/myusername/svn/ # Change this to the path you chose in Step 3, of course
</Location>

   If you want to keep your repository private — i.e. only accessible from the machine it’s hosted on, you can add a few lines, like so:

   <Location /svn ># I think you can change "/svn" to whatever you want the path to be on your server.
DAV svn
SVNPath /Users/myusername/svn/ # Change this to the path you chose in Step 3, of course

   Order Deny,Allow
Deny from all
Allow from 127.0.0.1
</Location>

5. Create your repository:

   svnadmin create --fs-type fsfs /Users/myusername/svn

6. Restart Apache

Whee, that was easy.

Browse to http://localhost:81/svn (substitute the appropriate port, of course, if you configured Apache differently) — and if you get something that looks like a really simple webpage, you’re set.

I’m kind of in love with Darwinports right now, in case you haven’t noticed. Next challenge: actually configuring a Subversion repository. I’m seriously crossing my fingers that this is easier than CVS.