On Wed, Jul 6, 2011 at 4:30 AM, Michael Wood <esiot...@gmail.com> wrote: > On 6 July 2011 10:14, Ken Wesson <kwess...@gmail.com> wrote: >> 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".
Maybe just "repository that isn't fragile or outright broken" then. ;) > If the CVS clients are the only ones doing the locking, then why not? ARE they the only ones doing the locking OR otherwise accessing the files, though? >> *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. No, just the concept of a reliable repository. ;) >> 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. Unsurprisingly. With apologies to Leonard McCoy: "Non-atomic commits. Funduscopic examination. What is this, the Dark Ages?" -- 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
