On 20 Nov, 12:17, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > > The reason is simply that without any server-side mechanism that at _least_ > allows for file-locking (something plain HTTP doesn't, nor does FTP), you > can't possibly make this work, as different concurrent requests of users > will end up corrupting the data. > > SVN works through Apache via HTTP. I REALLY believe you will spare yourself > _mucho_ troubles utilizing that.
Or perhaps something (else) which provides a comprehensive WebDAV implementation? I believe Subversion exports repositories via HTTP using various DAV-related methods, although I haven't needed to explicitly interact with Subversion repositories in such a way. Perhaps just exposing part of a filesystem using Apache plus mod_dav might be a sufficient alternative. Of course, as has already been said, lots of version control systems provide Web-based interfaces, and there are various graphical repository browsers which should know how to interact with these interfaces. Moreover, some distributed version control systems are able to understand repositories which are published as static files on the Web, being able to navigate to the appropriate resources without any dynamic magic happening on the server; Mercurial has support for this, although I imagine that it's really a read-only thing: http://www.selenic.com/mercurial/wiki/index.cgi/StaticHTTP Ultimately, if you're pushing things back to the server and it's on a "per change" basis, then a plain Web server isn't going to be sufficient. Otherwise, if users push their changes out only as new branches (in Mercurial terminology), they could upload such a branch in a single transaction (copy an archive to the server via FTP/scp, unpack it, move it into place) and have it exposed to the other users via a mechanism like the one mentioned above. Paul -- http://mail.python.org/mailman/listinfo/python-list
