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. ;)
In that case, pretty much all unix-based source control systems are "fragile or outright broken", as they all have a "files on disk" mode that doesn't require a server: cvs, svn, git, hg, etc. Even fossil - which uses an ACID SQL database to store things - does this. Perforce is the only exception I can think of. >> 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? Once you allow arbitrary commands to access the data on disk, you have problems. How you do file locking doesn't matter. >>> *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, As I mentioned, fossil does this. However, the database is embedded, meaning it uses those advisory locks to deal with inter-process coordination. >> 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. :) The only source control system I know that uses an ACID database doesn't need a back end server. >> 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. ;) Only if it's really badly designed. Like early versions of subversion. Of course, they broke even worse if you put them on a server instead of using direct file access. >>> 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. And all the popular ones have clients that can directly access the repository without a server. -- Sent from my Android tablet with K-9 Mail. Please excuse my brevity. -- 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
