Working Copy: Failed to update /path/ because unversioned /path/ already exists

I am a noob here on the list so please be gentle. I have done my
homework -- I searched through the mail list archives and issue database
using these keywords (and various combinations): "failed update file
unversioned exists commit". I've even read some of the Dev docs. I pried
this company from the cold hands of CVS almost a year ago, and most of
us are very happy with the change. I am trying for Linux converts, but
we're all WinXP clients with Linux (SuSE ES 9) servers for now. I just
have a few new coders, ex-Perfoce, left to convert...

        I have a few consistent problems with SVN Update and Commit actions,
reported by multiples of my SVN server's users, all with the same
command line client and TortoiseSVN (currently svn1.3.0/ Tsvn1.3.2/
svnserve1.2.1/ Apache2.0.49). They seem like relatively easy fixes on
the Client side, require no server or repo changes, and I am willing to
try to patch the client code myself. I wanted an experienced opinion on
them first.

Update issues:
        The top problem is with Updating directories that already contain
files/folders of the same name as data on the repository, but aren't yet
registered on the WC as being versioned. Multiple clients can use
automated tools to create "built" files that have the same exact path
and name, and sometimes even the exact same content. Who Commits these
"built" files and paths has more to do with luck and timing than anything.
        I understand our use case may be unusual here, but I don't understand
why Updates in these cases don't respond like any other HEAD-Local
Conflict situation, and save an *-r####.* and *-mine.* copy of the
file, rather than just failing. Or maybe a per-directory exception to
the "don't overwrite" rule could exist, only for build targets?
        M$/WindowsOS frequently holds filesystem locks on local files, most
often with art binary files, and it would be better for us to work
around these occasional locks as if they were Conflicts, rather than
just failing mid-Update. Sometimes these locks even cause problems in
the /.svn/tmp WC directories, "svn cleanup /path/" doesn't fix it, and
the whole directory has to be deleted and re-Updated.

Commit issue:
        A second, semi-related problem comes when any programmer tries to
Commit a text file when they don't have the latest HEAD revision. Rather
than attempting to Update and Merge such a file before the actual Commit
upload takes place, it seems the whole atomic Commit just fails
mid-action. They feel a Commit should only fail if there is a Conflict
between the Local and HEAD revision, and the system is unable to
automatically Merge. Many of the programmers here are used to working
with Perforce, and while I believe Subversion is far superior in many
ways, they find this particular Commit behavior counter-intuitive, and
cause for more manual work than otherwise necessary.

I realize our usage may be unusual, but I don't understand why there
aren't any configuration options to ignore the "never touch a
local file/folder not in the WC" rule, and instead save *-r####*
files when needed.
        I have created many batch files as temporary work-arounds to these
problems. I like the FSFS repository model and diff-only network
activity a lot. I plan to change the client to work for us, try not to
step on anyone's toes, and to submit patches when I can. This is just my
first call for help, so I can steer clear of any perceived pitfalls to
my plans.

        Thanks,
        Jared

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org