A crazy idea (that would work on OSes that support FUSE (or something equivalent).
- The user creates a filesystem (in a file) in their home directory. - They run a 'darcs-daemon' to mount the filesystem as part of the OS's real filesystem. This makes the user-mode filesystem indistinguishable from the 'real' filesystem to all processes. - When a pull/record/whatever runs, darcs effectively locks the filesystem from access by other processes until darcs completes. It can do this, because the darcs-daemon is running the show. - Darcs is the only process making changes: guaranteed! We now have the power to enforce transactional semantics including rollback. - The actual filesystem can be any freely available filesystem - it doesn't need to be written specifically for darcs. All we need to do is leverage FUSE to act as the gatekeeper. Something to think about anyway! Best Regards, James. On Thu, Apr 19, 2007 at 10:15:23AM -0700, David Roundy wrote: > On Thu, Apr 19, 2007 at 10:08:45AM -0700, David Roundy wrote: > > On Thu, Apr 19, 2007 at 08:56:57AM -0700, Samuel A. Falvo II wrote: > > > I'm curious to learn how difficult it would be to implement > > > transactional semantics to Darcs? This would prevent any kind of > > > corruption in the event of any kind of error at all. > > > > Pretty easy (almost) with the new hashed inventory format. We don't want > > truly atomic behavior on the pristine cache, as that'd slow darcs down too > > much (and I don't see any way of avoiding this slowdown, short of > > implementing our own journalling filesystem, which would definitely be a > > nice option, but not so easy). > > I should mention that transactional semantics in the working directory is > impossible to implement with any guarantees, because there's always the > possibility that halfway through an update someone will change permissions > of some of the working-directory files, or that disk space will be used up, > etc. I don't believe anything bigger than a single file can be updated > atomically. I suppose you could create a new directory and rename it over > an existing one, but you wouldn't want that behavior, since it'd mess up > any running programs with that directory as their working directory. > -- > David Roundy > Department of Physics > Oregon State University > _______________________________________________ > darcs-devel mailing list > [email protected] > http://lists.osuosl.org/mailman/listinfo/darcs-devel -- James Sadler [EMAIL PROTECTED]
signature.asc
Description: Digital signature
_______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
