You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Listman <li...@burble.net> on 2008/02/25 21:08:39 UTC
svn not atomic with file:/// access?
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.
i have 2 questions:
1) would svn:/// be faster than file:///
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?
i don't care about authentication (i have another means of controlling
that).
thx in advance.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn not atomic with file:/// access?
Posted by Toby Thain <to...@telegraphics.com.au>.
On 28-Feb-08, at 3:55 AM, Ignacio González T. wrote:
> El 25 Feb 2008 a las 15:19, Listman escribió:
>
> > 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?
>
> My two (Euro)cents:
>
> The main reason we swicthed from rcs (yes, bare rcs) to subversion
> was to avoid repository corruption associated with file:///-like
> access inherent to our development environment: Windows machines
> using a Windows-server directory as repository, mapped as a unit
> drive.
I believe this is also the architecture of Visual SourceSafe (shudder).
—Toby
>
> This environment worked quite well for years, until we had to use
> it remotely from another site. In this situation, network
> connections were more likely to fail, AND we began to notice
> repository corruption.
>
> We had to mentally adjust from the one-file-at-a-time-based,
> prelocking-based way to the system-wide-based, merging-base way,
> but, as hard as it resulted, it was worth while.
>
> --
> Saludos,
>
> <eliop_logo_Pegasus.jpg>
> Ignacio González Torquemada
> INGENIERO SW - DPTO. PRODUCTOS
> Avda. Valgrande, 8
> 28108 Alcobendas (Madrid) - España
> Tel. (+34) 91 383 57 47
> Fax. (+34) 91 302 92 49
> http://www.eliop.es
> e-mail: igtorque@eliop.es
>
> Este correo electrónico y cualquier fichero adjunto al mismo
> contienen información de carácter confidencial exclusivamente
> dirigida a su destinatario o destinatarios. En el caso de haber
> recibido este correo electrónico por error, se ruega notificar
> inmediatamente esta circunstancia mediante reenvío a la dirección
> electrónica del remitente y destruir el mensaje.
> P Antes de imprimir este correo, piense en su responsabilidad y
> compromiso con el medio ambiente
Re: svn not atomic with file:/// access?
Posted by Les Mikesell <le...@gmail.com>.
Ignacio González T. wrote:
>
>> 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?
>
> My two (Euro)cents:
>
> The main reason we swicthed from rcs (yes, bare rcs) to subversion was to avoid
> repository corruption associated with file:///-like access inherent to our
> development environment: Windows machines using a Windows-server directory
> as repository, mapped as a unit drive.
>
> This environment worked quite well for years, until we had to use it remotely from
> another site. In this situation, network connections were more likely to fail, AND
> we began to notice repository corruption.
>
> We had to mentally adjust from the one-file-at-a-time-based, prelocking-based
> way to the system-wide-based, merging-base way, but, as hard as it resulted, it
> was worth while.
If you _wanted_ file-at-a-time access with rcs under the covers, CVS
with pserver access might have been an easier transition. Most people
like the atomic directory/project actions in subversion better, though.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn not atomic with file:/// access?
Posted by "Ignacio González T." <ig...@eliop.es>.
El 25 Feb 2008 a las 15:19, Listman escribió:
> 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?
My two (Euro)cents:
The main reason we swicthed from rcs (yes, bare rcs) to subversion was to avoid
repository corruption associated with file:///-like access inherent to our
development environment: Windows machines using a Windows-server directory
as repository, mapped as a unit drive.
This environment worked quite well for years, until we had to use it remotely from
another site. In this situation, network connections were more likely to fail, AND
we began to notice repository corruption.
We had to mentally adjust from the one-file-at-a-time-based, prelocking-based
way to the system-wide-based, merging-base way, but, as hard as it resulted, it
was worth while.
--
Saludos,
Ignacio González Torquemada
INGENIERO SW - DPTO. PRODUCTOS
Avda. Valgrande, 8
28108 Alcobendas (Madrid) - España
Tel. (+34) 91 383 57 47
Fax. (+34) 91 302 92 49
http://www.eliop.es
e-mail: igtorque@eliop.es
Este correo electrónico y cualquier fichero adjunto al mismo contienen información de carácter confidencial
exclusivamente dirigida a su destinatario o destinatarios. En el caso de haber recibido este correo electrónico por
error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente
y destruir el mensaje.
P Antes de imprimir este correo, piense en su responsabilidad y compromiso con el medio ambiente
Re: svn not atomic with file:/// access?
Posted by Les Mikesell <le...@gmail.com>.
Talden wrote:
>
>> 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.
Assuming the OS file locking works, the concurrency issues should be
handled correctly - but that's a big assumption, especially if you have
a mix of OS's across the clients and file server. Using svn: and http:
access will have the same concurrency issues but everything is on the
same OS.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn not atomic with file:/// access?
Posted by Talden <ta...@gmail.com>.
On Tue, Feb 26, 2008 at 12:19 PM, Listman <li...@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 <li...@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn not atomic with file:/// access?
Posted by John Peacock <jo...@havurah-software.org>.
Miller, Eric wrote:
> I don't want to hijack this thread, but can svn+ssh:// have the same
> issues? Since svn+ssh:// fires up a new svnserve process for each
> repository access session there is no "central" server to handle
> concurrency issues.
Both file:// and svn+ssh:// use file locking, so you /shouldn't/ have
issues, except if the repository is located on a remotely mounted
filesystem without an effective filesystem lock. Specifically, there
are some NFS implementations which don't have very good lock support (or
people turn off lockd because it makes everything "slower"). :(
The performance issue of always having to start up an svnserve session
for each connection (on top of starting up an SSH connection), means
that svn+ssh:// cannot be considered a high performance method. But it
can be configured as a very high security system, ala:
http://subversion.tigris.org/faq.html#ssh-svnserve-location
http://svn.collab.net/repos/svn/trunk/notes/ssh-tricks
YMMV
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: svn not atomic with file:/// access?
Posted by "Miller, Eric" <Er...@amd.com>.
> 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.
I don't want to hijack this thread, but can svn+ssh:// have the same
issues? Since svn+ssh:// fires up a new svnserve process for each
repository access session there is no "central" server to handle
concurrency issues.
If so, this would explain a lot of the intermittent failures we've been
seeing with svn+ssh://.
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn not atomic with file:/// access?
Posted by Toby Thain <to...@telegraphics.com.au>.
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 <li...@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@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Re: svn not atomic with file:/// access?
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2008-02-28 15:58:39 -0500, Harvey, Edward wrote:
> I'll add something here, that's really simple:
>
> file:// Only good for a single user, very fast and simple, no server
> required.
You should have said: as the single access method and only locally.
I am a single user of my own private repository, but I have different
machines, and I often do concurrent accesses. I didn't know this could
lead to problems.
> (I believe it's ok to use file:// for multiple users,
> as long as those users are all on the same machine; no network file
> shares.)
Without locking, concurrent accesses are not OK with NFS, even for
the same user on the same machine.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn not atomic with file:/// access?
Posted by Listman <li...@burble.net>.
On Feb 26, 2008, at 10:59 AM- Feb 26, 2008, Paul Koning wrote:
>>>>>> "Andy" == Andy Levy <an...@gmail.com> writes:
>
>>> 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..
>
> Andy> As I said in my earlier response, safety should take priority
> Andy> over speed when talking about a system like Subversion. There
> Andy> is a tradeoff that has to be made, but IMHO that analysis
> Andy> shouldn't include leaving the door open to have the entire
> Andy> repository deleted by an errant keystroke on the part of any
> Andy> user.
>
> ... or messed up. Deletion of a whole repository is easy to detect.
> Grab a backup and you're back in business (minus some hours of work,
> of course).
>
> The nastier problem is a user error, or application/OS error, that
> scribbles on the repository in a non-obvious way. That might leave
> you with bad data, or a missing commit, or other issues. Depending on
> the specifics, it might go undetected for a long time. Perhaps long
> enough that you no longer have backups far enough back...
>
> I always use svn:// access for everything, for a repository that's
> well over 10 GB, the working directory tends to be several GB.
> Checkout is a bit of a wait, but you only do that a few times per
> year. The rest is quite acceptable. Worst case is about the same
> speed as CVS, best case is much faster (and functionaly vastly
> superior!)
>
> paul
>
well i think everyone should have an svnsync backup repos chugging
away in the back
ground for this very reason.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn not atomic with file:/// access?
Posted by Les Mikesell <le...@gmail.com>.
Harvey, Edward wrote:
>
> http:// Not as fast as svn://, but not unbearable. Very flexible in
> terms of
> authentication and access control. Installation is not
> for the faint
> of heart. The average new user would have a very hard
> time figuring out
> how to get this working the first time.
Many linux distributions have it packaged so something lie:
yum install subversion httpd mod_dav_svn
(or an equivalent apt-get command) does the bulk of the work so all you
have to do yourself is tweak the additions to the httpd.conf file for
the repository location and access control.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: svn not atomic with file:/// access?
Posted by "Harvey, Edward" <Ed...@patni.com>.
I'll add something here, that's really simple:
file:// Only good for a single user, very fast and simple, no server
required.
(I believe it's ok to use file:// for multiple users, as
long as those
users are all on the same machine; no network file
shares.)
svn:// Very good, fast, simple server to install svnserve. Simplest
and fastest
way to enable network access. However, until 1.5 some
features are not
available. Assuming you want usernames (helps track
changes) then
passwords must be stored plain-text in a file. (Can
root
configure the file once, and assign blank passwords for
everyone?
I don't know.)
svn+ssh:// You really want to configure RSA keys for
auto-authentication. Rather
slow. But reliable and usable otherwise.
http:// Not as fast as svn://, but not unbearable. Very flexible in
terms of
authentication and access control. Installation is not
for the faint
of heart. The average new user would have a very hard
time figuring out
how to get this working the first time. But it's
necessary if you need
to grant permissions on the per-folder level, or
authenticate against
something other than plaintext. (Until 1.5, when
svnserve will be able
to authenticate flexibly.)
https:// Exactly the same as http:// but with ssl for added
security & complexity.
> -----Original Message-----
> From: Paul Koning [mailto:Paul_Koning@dell.com]
> Sent: Tuesday, February 26, 2008 1:59 PM
> To: andy.levy@gmail.com
> Cc: listman@burble.net; troy.bull@gmail.com;
> users@subversion.tigris.org
> Subject: Re: svn not atomic with file:/// access?
>
> >>>>> "Andy" == Andy Levy <an...@gmail.com> writes:
>
> >> 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..
>
> Andy> As I said in my earlier response, safety should take
> priority Andy> over speed when talking about a system like
> Subversion. There Andy> is a tradeoff that has to be made,
> but IMHO that analysis Andy> shouldn't include leaving the
> door open to have the entire Andy> repository deleted by an
> errant keystroke on the part of any Andy> user.
>
> ... or messed up. Deletion of a whole repository is easy to detect.
> Grab a backup and you're back in business (minus some hours
> of work, of course).
>
> The nastier problem is a user error, or application/OS error,
> that scribbles on the repository in a non-obvious way. That
> might leave you with bad data, or a missing commit, or other
> issues. Depending on the specifics, it might go undetected
> for a long time. Perhaps long enough that you no longer have
> backups far enough back...
>
> I always use svn:// access for everything, for a repository
> that's well over 10 GB, the working directory tends to be several GB.
> Checkout is a bit of a wait, but you only do that a few times
> per year. The rest is quite acceptable. Worst case is about
> the same speed as CVS, best case is much faster (and
> functionaly vastly
> superior!)
>
> paul
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
http://www.patni.com
World-Wide Partnerships. World-Class Solutions.
_____________________________________________________________________
This e-mail message may contain proprietary, confidential or legally
privileged information for the sole use of the person or entity to
whom this message was originally addressed. Any review, e-transmission
dissemination or other use of or taking of any action in reliance upon
this information by persons or entities other than the intended
recipient is prohibited. If you have received this e-mail in error
kindly delete this e-mail from your records. If it appears that this
mail has been forwarded to you without proper authority, please notify
us immediately at netadmin@patni.com and delete this mail.
_____________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn not atomic with file:/// access?
Posted by Paul Koning <Pa...@dell.com>.
>>>>> "Andy" == Andy Levy <an...@gmail.com> writes:
>> 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..
Andy> As I said in my earlier response, safety should take priority
Andy> over speed when talking about a system like Subversion. There
Andy> is a tradeoff that has to be made, but IMHO that analysis
Andy> shouldn't include leaving the door open to have the entire
Andy> repository deleted by an errant keystroke on the part of any
Andy> user.
... or messed up. Deletion of a whole repository is easy to detect.
Grab a backup and you're back in business (minus some hours of work,
of course).
The nastier problem is a user error, or application/OS error, that
scribbles on the repository in a non-obvious way. That might leave
you with bad data, or a missing commit, or other issues. Depending on
the specifics, it might go undetected for a long time. Perhaps long
enough that you no longer have backups far enough back...
I always use svn:// access for everything, for a repository that's
well over 10 GB, the working directory tends to be several GB.
Checkout is a bit of a wait, but you only do that a few times per
year. The rest is quite acceptable. Worst case is about the same
speed as CVS, best case is much faster (and functionaly vastly
superior!)
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn not atomic with file:/// access?
Posted by Andy Levy <an...@gmail.com>.
On Tue, Feb 26, 2008 at 12:36 PM, Listman <li...@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 <li...@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 <li...@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn not atomic with file:/// access?
Posted by Listman <li...@burble.net>.
On Feb 26, 2008, at 8:06 AM- Feb 26, 2008, Troy Bull wrote:
> On Mon, Feb 25, 2008 at 5:19 PM, Listman <li...@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 <li...@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.
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..
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn not atomic with file:/// access?
Posted by Listman <li...@burble.net>.
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 <li...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn not atomic with file:/// access?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 25, 2008, at 16:03, Ryan Schmidt wrote:
> 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.
I meant "rm -rf /path/to/repo"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn not atomic with file:/// access?
Posted by Ryan Schmidt <su...@ryandesign.com>.
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 <li...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn not atomic with file:/// access?
Posted by Listman <li...@burble.net>.
On Feb 25, 2008, at 1:13 PM- Feb 25, 2008, Andy Levy wrote:
> On Mon, Feb 25, 2008 at 4:08 PM, Listman <li...@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.
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.
thx
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn not atomic with file:/// access?
Posted by Andy Levy <an...@gmail.com>.
On Mon, Feb 25, 2008 at 4:08 PM, Listman <li...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org