On Wed, Jul 6, 2011 at 3:33 AM, Meikel Brandmeyer <m...@kotka.de> wrote: > Hi, > > Am Mittwoch, 6. Juli 2011 09:23:08 UTC+2 schrieb Ken Wesson: > >> How would that be implemented, though? Without the server running to >> enforce mutual exclusion and detect edit collisions and everything, >> the whole notion of "checkin" and "checkout" appears to become >> meaningless. > > Obviously this is implemented in cvs because the form above comes from its > documentation. In fact since it is on the local machine I would expect > something like flock or lockf to work. What happens if “local” means NFS...
Sorry, but I think version control and, particularly, dealing with edit collisions is not something you can solve as easily as just slapping a lock onto each file access, or else version control servers could just be FTP servers that locked their shared files during each access. > So in fact I would consider “local” to be the trivial case to ensure mutual > exclusion and edit collisions detection if everyone obeys to flock or such. And then there's the niggling little matter of Unix file locks being advisory rather than mandatory. Do you really want proper resolution of edit collisions (or, worse, the integrity of the under-the-hood state maintained for the repository vis a vis making sense and being valid data structures) to be entirely on the honor system? At *minimum* it would seem that a real database with ACID and transactions would be needed -- A to avoid race conditions (no advisory locks here!), C to keep the internal state invariants valid, I to be able to deal with edit collisions in a sane manner, and D for the obvious reasons. And a suitable software front-end. And now we're back to having at least one server in the mix, namely the DBMS at the backend. :) Here's a simple question to ask yourself whenever considering using advisory file locks to guard complex on-disk data with invariants to maintain: *If the power goes off halfway through some kind of transaction, can the system recover without a lot of manual hacking to patch up the state of the on-disk data structures? Will my losses be limited solely to the one transaction in progress at the moment of the outage?* If you don't have a satisfactory answer there, then you probably need a real database. Of course perhaps you are clever and can design your own on-disk data structures that will fail-soft in some manner under such circumstances and convince yourself beyond a reasonable doubt that it'll work, but if not ... -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
