在这个小节，我们会描述最普通的原始WebDAV客户端（写作的时刻），和它们是如何与使用SVNAutoversioning指示的mod_dav_svn服务器的运作。RFC 2518是一个有点大，并且有一点太灵活。每个WebDAV客户端的行为都有些许区别，并且产生许多不同的小问题。
Windows 98、2000和XP有一个集成的WebDAV客户端叫做“网络文件夹”，在Windows 98，这个特性需要明确安装；如果提供，一个“网络文件夹”就会出现在我的电脑，在Windows 2000和XP，只需要简单得打开我的网络位置，运行添加网络位置图标。当出现提示，输入一个WebDAV的URL，我的网络位置中就会出现一个共享文件夹。
大多数写操作对于自动版本化的mod_dav_svn服务器工作正常，但是有一些问题：
如果一个Windows XP电脑是一个NT域的成员，它看起来不能连接到WebDAV共享，重复提示要输入用户名和密码，即使Apache服务器没有要求进行认证！如果这个机器不是NT域的一部分，这个共享可以成功装载。
这个问题源于Windows XP创建网络文件夹快捷方式（.lnk文件）的方法的bug。它有时候会使用“UNC” （Universal Naming Convention） 路径来代替WebDAV共享URL，这导致资源管理器尝试使用SMB而不是HTTP来进行连接。
这个问题的解决方法是在Windows 2000创建.lnk快捷方式，然后拷贝到Windows XP电脑，如果有人可以逆转.lnk文件的格式，也可以使用十六进制编辑器来“修正”快捷方式。
一个文件不可以直接在共享中打开编辑；它可能一直是只读的。mod_dav_lock技术也无能为力，因为网络文件夹根本不使用LOCK方法，前面提到的“拷贝、编辑和再拷贝”根本不工作。在共享中的文件可以成功的被本地修改的拷贝覆盖。
Apple的OS X操作系统也集成了WebDAV客户端，从Finder选择Go菜单的“Connect to Server”，输入一个WebDAV的URL，它会作为一个磁盘在桌面出现，就像任何文件服务器。[49]
很不幸，客户端拒绝与一个自动版本化的mod_dav_svn工作，因为它缺乏LOCK支持，Mac OS X在初始化HTTP的OPTIONS特性交换时会发现缺失了LOCK能力，因而决定以只读方式装配Subversion版本库，之后，不可以进行写操作。为了将版本库按照读写方式装配，你必须使用前面讨论的mod_dav_lock技巧。一旦锁定看起来工作了，共享会运作良好：文件可以直接以读/写模式打开，尽管每次存储操作会导致客户端对临时位置执行一个PUT，对原文件的DELETE操作和把临时资源MOVE到原文件。每次存盘会产生三个新的Subversion修订版本！
还要警告一点：OS X的WebDAV客户端可以对HTTP重定向完全敏感，如果你不能装配版本库，你可以在httpd.conf开启BrowserMatch指示：
BrowserMatch "^WebDAVFS/1.[012]" redirect-carefully
Nautilus是GNOME桌面的官方文件管理器/浏览器，它的主页在http://www.gnome.org/projects/nautilus/，只需要在Nautilus窗口中输入一个WebDAV的URL，DAV共享就会像本地磁盘一样出现。
通常情况下，Nautilus 2与自动版本化的mod_dav_svn一起工作相当的好，只是有下面一些警告：
任何在共享里直接打开的文件是只读的，即使mod_dav_lock的技巧也看起来无效。Nautilus看起来从没有关注过LOCK方法，“本地拷贝、编辑和拷贝回去”的技巧还可以工作，但是很不幸，Nautilus的覆盖旧文件是通过首先DELETE进行的，这创建了一个额外的修订版本。
当覆盖或创建一个文件，Nautilus首先PUT一个空文件，然后使用第二个PUT覆盖它，这创建了两个Subversion文件系统修订版本，而不是一个。
当删除了一个集合，它对每个独立的孩子而不是集合本身发出HTTP的DELETE操作，这会创建一系列新的修订版本。
Linux davfs2是一个Linux内核的文件系统模块，它的开发位于http://dav.sourceforge.net/。一旦安装，一个WebDAV网络共享可以使用普通的Linux的mount命令装配。
一个公开的秘密就是DAV客户端不会与mod_dav_svn的自动版本化完全工作正常，即使一个单独对服务器的写尝试需要LOCK请求作为前提，而这是mod_dav_svn不支持的。此时，还没有数据表明是否可以使用mod_dav_lock解决这个问题。