Subversion working copy via Samba

Hello,

I don't know is this a Samba or Subversion (or my faulty config) related
issue so I'll start here. I'd like to clarify that the need to have just one
working copy (and not one per user on his/her local disk) is vital here.

Also, I'd like to note that this same mail was sent to Samba's list as I
can't yet figure out is this a Samba or SVN issue.

My situation:
- CentOS6 server
- Active Directory-enabled environment
- Server is connected to AD, users are synced up
- All users are in AD group "Production" which is available as a local group
on the server via Winbind
- There's a /data/html on an ACL-enabled EXT3 volume,
ACL entry:
# file: data/html
# owner: root
# group: production
# flags: -s-
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x

Samba:
[html]
    # stop SVN working copies from going belly-up
    delete readonly = yes

    path = /data/html
    read only = No
    browseable = Yes
    force group = production
    valid users = @production
    force create mode = 0664
    force directory mode = 0775
    inherit acls = Yes

Target:
- check out a working copy to this directory
- allow only members of @Production to access it
- allow various Subversion clients to be used via Samba on the working copy
- allow for using SVN directly on the server (not via Samba, MUCH faster for
large operations like checkout) without the need to fix permissions
afterward (seamlessly)

Now, I get most of it done:
- I login via SSH and do a checkout
- access the share via Samba (Linux, Fedora 14), it works
- can commit/update/delete on either side, no issues

But, as soon as my co-worker on Win7/TortoiseSVN deleted a file (via Samba),
he gets (Q:\ points to this share):

Commit succeeded, but other errors follow:
Error bumping revisions post-commit (details follow):
In directory 'Q:\webs\<censored>\trunk\images'
Error processing command 'committed' in 'Q:\webs\<censored>\trunk\images'
Can't set file
'Q:\webs\<censored>\trunk\images\.svn\prop-base\avatar_small.png.svn-base'
read-write: Access is denied.

and from then on, the working copy is so badly damaged (locked, missing
files/directories), etc. that I haven't found a way to fix it.

Examining the permissions on the file in question, it seems Subversion sets
the access mode to r--r--r-- as to avoid tampering (?) and the Windows
client isn't able to change it. The other reason might be that one user is
changing the file another user owns, but they're in the same group.

So, my question is: is there anybody out there who has a similar setup which
in fact runs OK? Also, am I missing something obvious here (except for the
weird SVN usage pattern)?

Thanks,

-- 
Dado