On 6 July 2011 10:37, Ken Wesson <kwess...@gmail.com> wrote: > 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. ;)
Perhaps, but I'd still say that even if the repository is made available over the network and only the server is directly accessing the repository, it is still a repository and the server is not accessing it over the network, so the repository itself doesn't have anything to do with the network ;) >> 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? Yes, unless you have malicious users, in which case you will need the server. I'm not saying it's not a potential security problem. Just that co-operative locking of files can work depending on the circumstances. >>> *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?" :) -- 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
