There is one option on the market for this problem:
WsgiDAV is a python WebDAV server that offers a variety of backends including the DVCS mercurial, plus some other fashionable stores (couchdb, mongodb, MySQL, App Engine). Note the current version claims "This is not production code."
It seems to different versioning than SVN's WebDAV, autoversioning, allowing you to commit changesets consisting of multiple updates at once (by dragging from "edit" to "released" folders and so, whereas SVN+WebDAV's autoversioning creates far too many commits, creating a version per-change. So it's not quite wholly auto-versioning, but it does not require command-line access, and is IMO a superior model.
Thinking about this more generally... I don't recommend the auto-commit WebDAV+SVN thing at all. As you say, "commits in auto-versioning are frequent". But they are so very frequent, and usually meaningless.
My own solution is to run a git or mercurial repository on my server, and use a cron-job to version changes to it at regular intervals. Ugly, but functional, and requires no special server setup/no special apache modules/etc. Better yet, I can access said repository over WebDAV, or SFTP or a windows/apple fileshare, or local DVCS mirror, depending on my needs, and they all work seamlessly.
Git, for example, has quite good file-move detection, so this reduces the need for WebDAV access per se. Whereas if one moves a directory in an SVN checkout without going through an access layer which translates this to a svn mv command, then horrible corruption can result. AFAICT, the chief benefit of WebDAV+SVN is that it prevents you from breaking your own checkout in this way.
On the other hand, the "compact databases" of git or mercurial are not a real reason to prefer them over SVN in this case. However, if you are looking at having to deal with real sync conflicts, I would recommend either of them over subversion for their superior conflict resolution and general lower level of fuss/flexibility.
