Re: Atomic updates

On Tuesday 22 November 2005 11:24 am, Scott Palmer wrote:
> On 22-Nov-05, at 12:15 PM, Erik Huelsmann wrote:
> > On 11/22/05, Thompson, Graeme (AELE)
> >
> > <Graeme.Thompson@smiths-aerospace.com> wrote:
> >> You could easily write a script to give you atomic updates:
> >>
> >> Copy your current working directory.
> >> Run svn update on your working directory
> >> If (successful)
> >> {
> >> delete your copy
> >> }
> >> Else
> >> {
> >> delete your working directory
> >> move the copy back to your working directory
> >> }
> >>
> >> This could easily be done on any of the operating systems that svn
> >> supports
> >>
> >> Just run this script to update you working directory and you will
> >> have what you want.
> >
> > But it's not atomical: it's not a fail or succeed operation: 'delete
> > your working directory' can fail half way, so that it's impossible to
> > copy over the copy-working-dir.
>
> So change that to read "rename your working directory" instead of
> delete. It would require a bit of messing around for sure, but I
> don't think it is impossible.. perhaps impractical.
>
> Scott
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

        Here's a scenario to consider when talking about this, keeping in mind that
SVN is already greedy about the diskspace it consumes:

        A single server hosts the websites for multiple webdevelopers running
subversion: the server has a ~32G hard drive. Two of them (call 'em "dev1"
and "dev2") are heavy into database munging, and having anywhere from 2-10G
of unversioned data in their svn-controlled directories. One (call 'im
"dev3") doesn't care about these massive database files and whatnot, but
loves to hold onto 4 different branches of development, plus the trunk
(chewing-up about 100-300M per checkout). All told, these three developers
have taken about 18G of the server's space, leaving 14G available.
        In the morning, "dev1" decides to update his checkout to have the most
current data (his svn dirs are currently 8G in size): this starts eating-away
at the server's free space. A minute later, "dev2" does the same thing (his
svn dirs is also about 8G in size): At the height of the operation, they'll
have taken 32G of space, hitting the server's maximum capacity.
        As "dev1" gets to the height of the update, "dev3" updates his directory,
eating away the last of the server's space: "dev2" encounters a problem
wherein one of the directories with unversioned data didn't get completely
copied, but svn doesn't realize this, since it's unversioned. The operation
appears to succeed, the original copy of "dev2"'s wc is deleted, leaving one
of his database files mysteriously small...

-- 
Best Regards,
Dan Falconer
"Head Geek",
AvSupport, Inc. (http://www.partslogistics.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org