On 6 July 2011 10:14, Ken Wesson <kwess...@gmail.com> wrote: > 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.
Maybe so, but that is all beside the point. The point was that "repository" needn't mean "networked". >> 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 If the CVS clients are the only ones doing the locking, then why not? > *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, This is why various people moved away from CVS. To get atomic commits etc. > 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. :) Right, I agree it's best to have a server controlling access to the repository, but that does not mean that the concept of a repository is linked to having a server or a network. > 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?* Right, and this is a problem with CVS. > 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 ... CVS is an old version control system that was far better than the other things around at the time it was invented, but most people seem to agree that other, more modern, version control systems are better and/or more reliable. -- Michael Wood <esiot...@gmail.com> -- 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
