On Thu, Apr 19, 2007 at 10:23:53AM -0700, Samuel A. Falvo II wrote: > On 4/19/07, David Roundy <[EMAIL PROTECTED]> wrote: > >I should mention that transactional semantics in the working directory is > >impossible to implement with any guarantees, because there's always the > > I meant within the context of darcs only. If another application is > running that is tweaking the filesystem out from underneath darcs, > well, we obviously can't control that, and the user gets what he > deserves. ;D
I disagree, in the case of the working directory. We need to code pessimistically, since it's perfectly fair for the user to do things in the working directory while darcs is running. Admittedly, they may not get the effect they want, but they shouldn't be able to corrupt darcs by so doing (with the more restrictive definition which says that messing up the working directory doesn't count as corrupting the repository). The problem is that when we're talking about transactional semantics, we're talking precisely about exceptional circumstances--meaning error cases, things that aren't supposed to happen, but really do happen in real life. And that's something we just need to deal with. On windows, we can't modify any file that any other program has open. This can change at any time, and there's nothing we can do about it, and telling users that if they have automated backup software, using darcs while that software is running could corrupt their repository, and it's their own fault because they shouldn't be doing that, that's no good. On posix systems, we still have many filesystems that don't obey posix semantics, and that's something we have to live with. With posix filesystem semantics, the *only* atomic operations that exist--that I'm aware of--operate on a single file. On windows we don't even have that... or at least, noone has told me how to do anything atomically, and we don't. How would you implement transactional semantics for the working directory, even in the best of circumstances? I'll admit, this is certainly a subject I've never actually studied, so there may be some sort of a technique that I haven't thought of. We could certainly implement transactional semantics on the pristine cache by writing a fresh copy for each change, and only deleting the old one when we're finished, but that sort of approach on the working directory just won't work. -- David Roundy Department of Physics Oregon State University _______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
