On Tuesday 22 November 2005 15:07, Erik Huelsmann wrote:
> On 11/22/05, Sergey Proskurnya <alaley@gmail.com> wrote:
> > Alex R. Mosteo пишет:
> > > Célio Cidral Junior wrote:
> > >> 2005/11/21, Leon Zandman <lzandman@lode.nl>:
> > >>> I would also like atomic updates. It happened to me once that an
> > >>> update failed and I had to manually restore many files.
> > >>
> > >> At least I'm not alone :)
> > >
> > > I'm for it, but optional. I have done some massive updates of
> > > multimedia files from slow connections that would be hell if they were
> > > atomic.
> >
> > Agree with you.
> > BTW, is there such enhancement request in SVN Issue Tracker?
>
> No, because it's impossible: atomic means that everything changes, or
> nothing *in 1 operation*.
>
> There is no operating system which lets us rename more than 1 file per
> rename operation, so, it's impossible.
Well, that's right.
But you can try to achieve the illusion of being atomic to the user-space
processes (at least with enough rights).
That's what I'm planning for fsvs: using unionfs
(http://www.fsl.cs.sunysb.edu/project-unionfs.html) or something similar (I
remember having read about at least one other, but I can't find that ATM).
It should work like this: checkout all changed files in the same directory
structure into a separate (temporary) directory. When that has finished,
mount that as overlay over your wc.
Voila! One atomic operation, and all or nothing is visible.
Then it's only a question of your uninterruptible power supply if you manage
to move the files into the underlying filesystem (where they belong). When
this is done, unmount the directory and you can work again.
Granted, this is not fully thought through; but it'll be a time until I get to
these parts anyway. Much time to think about cornercases and possible
problems.
> I'd rather have you report bugs (with reproduction recipies!) which
> show us how to create working copies in an unrepairable state: that's
> something we *can* work on.
That's surely the best way to go forward now.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 22 15:31:10 2005