On Tue, Feb 26, 2008 at 12:36 PM, Listman <listman_at_burble.net> wrote:
>
> On Feb 26, 2008, at 8:06 AM- Feb 26, 2008, Troy Bull wrote:
>
>
>
> > On Mon, Feb 25, 2008 at 5: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?
> >>
> >
> > I think you will have a hard time finding concrete answers to this
> > because it is such a bad idea almost no one on this list would do it.
> > Especially when setting up a "server' is as trivial as "svnserve -d -r
> > /path/to/repo"
>
> I think you're missing the point though. The biggest problem with
> Subversion
> is its performance and we are trying to do as much as possible to try
> and speed things
> up in our design environments. file:/// is faster than any of the
> access mechanisms
> and that is a very compelling argument to at least try it out.
Have you quantified the performance difference in your environment?
> of course we'd like to use the most robust mechanism for access
> and of course we'd prefer it if users can't delete the repository but
> we're also
> trying to make Subversions performance palatable to our user-base, which
> is proving to be a challenge..
As I said in my earlier response, safety should take priority over
speed when talking about a system like Subversion. There is a tradeoff
that has to be made, but IMHO that analysis shouldn't include leaving
the door open to have the entire repository deleted by an errant
keystroke on the part of any user.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-26 18:41:56 CET