Re: svn not atomic with file:/// access?

On Tue, Feb 26, 2008 at 12:19 PM, Listman <listman_at_burble.net> wrote:
>
>
> On Feb 25, 2008, at 2:03 PM- Feb 25, 2008, Ryan Schmidt wrote:
>
> >
> > On Feb 25, 2008, at 15:40, Listman wrote:
> >
> >> On Feb 25, 2008, at 1:13 PM- Feb 25, 2008, Andy Levy wrote:
> >>
> >>> On Mon, Feb 25, 2008 at 4:08 PM, Listman <listman_at_burble.net> wrote:
> >>>
> >>>> hi, we have a number of users committing to a network appliance
> >>>> using
> >>>> the file:/// protocol on our local network. their local
> >>>> workspaces are
> >>>> also on the same network appliance.
> >>>
> >>> Very, very bad idea. file:/// access is intended only for single-
> >>> user,
> >>> local, testing/debugging usage. Over a network, and with multiple
> >>> users, is a very quick & easy route to repository corruption or
> >>> complete loss.
> >>>
> >>>> i have 2 questions:
> >>>>
> >>>> 1) would svn:/// be faster than file:///
> >>>
> >>> No (it'll be marginally slower), but it'd be safer. And (IMO,
> >>> anyway)
> >>> with a source control system, safety trumps speed.
> >>>
> >>>> 2) do i need to be using svn:/// to ensure that checkins are
> >>>> atomic?
> >>>> is there a potential for repository corruption with file:/// in
> >>>> this
> >>>> situation?
> >>>
> >>> file:/// should be atomic just like svn:// - but when you're using
> >>> it
> >>> the way you are, weird things can happen.
> >>>
> >>>> i don't care about authentication (i have another means of
> >>>> controlling
> >>>> that).
> >>>
> >>> But you should care about it. With file:///, one errant keypress can
> >>> delete or corrupt your whole repository; all users require full,
> >>> unrestricted access to the repository DB in this mode.
> >>
> >> Thx for the feedback Andy, alot of your concerns are valid but in
> >> our situation
> >> we handle all subversion interactions through a wrapper script.
> >> There's no
> >> chance that a user can do the wrong thing, we don't let them.
> >
> > You don't have the opportunity not to let them. :) With file:///
> > access, all users by necessity have complete access to all
> > repository files. So if your repository is at file:///path/to/repo,
> > any user can type "rm -rf file:///path/to/repo" and your repo will
> > be GONE. Please stop using file:/// access and start using a server
> > process like svnserve so that this is no longer possible.
> >
> >> That being said, can you be more specific than "weird things might
> >> happen"?
> >> I'd like to understand the issues so that we can make a decision on
> >> the
> >> file access question.
> >
> >
>
> point taken Ryan, we'll certainly consider changing to svnserve. we
> don't want anyone to delete the repository :(
>
> i do appreciate all the concern for my environment but any chance
> someone can answer my actual question, namely what weird things can
> happen with file:/// ? I'm just interested to know what the mechanics
> of this are. is the only issue that file:/// leaves the repos wide
> open for deletion on the file-system?
>
> thx again.

I'd say Andy answered that quite clearly already. I expect that
'weird' in this context would extend to any number of non-synchonised
concurrency issues. Andy has clearly expressed the risk of corruption
but I expect you can also get broken updates/checkouts by doing so
while another user is writing.

--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org