On 25-Feb-08, at 5:19 PM, Listman 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?
Like any multi-user database, you need a server such as svnserve or
Apache to safely mediate concurrent access. As Les implies,
Subversion may try to use file locking in this situation (sorry, I
can't say for certain), but this leaves you dependent on the correct
functioning of locking in your particular OS/filesystem layers.
--Toby
>
> thx again.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
---------------------------------------------------------------------
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 17:06:52 CET