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, which, when googled, returned only results related to TortoiseSVN:

$ 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 unafraid 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.

More info about the site.

If you aren’t familiar with the plugin, it duplicates the image management dialogue to permit you to attach images to a post as metadata using a simple graphical interface — instead of having to locate, copy, and paste the URL into a custom field.

The new version allows fields to be accessed properly outside the Wordpress Loop as well as on archive and category pages. It fixes several bugs including broken template tags and some data loss bugs that were related to post revisions, autosaves, and scheduled / future posts. It’s been tested with Wordpress 2.8.6 and will likely still work with earlier versions going back to 2.7.

I’d like to extend a big thank you to everyone who submitted bug reports and fixes for the plugin — I hope you’ll contact me so that I can give you credit (name and URL) in the documentation.

Imagine the following (simplified) models:

class Blog(models.Model):
  owner = models.OneToOneField(User, primary_key=True)
  title = models.CharField(max_length=32)


class Entry(models.Model):
  blog = models.ForeignKey(Blog)
  slug = models.SlugField(max_length=255, db_index=True)
  headline = models.CharField(max_length=255)
  content = models.TextField()


If I want to show the user only their own entries in the admin object list, I can filter the list in the ModelAdmin.queryset method — simple as pie:

class EntryAdmin(admin.ModelAdmin):
  def queryset(self, request):
    qs = super(EntryAdmin,self).queryset(request)
    return qs.filter(blog__owner=request.user)


Now, say I want to also limit what blogs the user can assign the entry to. There’s a useful little ModelAdmin method called formfield_for_dbfield, but it doesn’t receive the request as an argument. What to do?

Well, the ModelAdmin.get_form method does receive the request as an argument, and it gets called before formfield_for_dbfield. So let’s just put the request object somewhere that we can get to it later:

class EntryAdmin(admin.ModelAdmin):
  def get_form(self, request, obj=None):
  self.request = request
  f = super(EntryAdmin,self).get_form(request, obj)
  return f


Then when we call formfield_for_dbfield we have easy access to the request:


class EntryAdmin(admin.ModelAdmin):
  def formfield_for_dbfield(self, dbfield, **kwargs):
    if dbfield.name == 'blog':
      kwargs['queryset'] = Blog.objects.filter(owner=self.request.user)
    return super(EntryAdmin, self).formfield_for_dbfield(dbfield, **kwargs)


Not the world’s most elegant solution, but simple and effective. And there’s plenty more you can do with these techniques. Gotta love Django!