The umask thing is a pain.
I think the real problem is that the wrapper script isn't installed by
default. New admins don't know that they need to install the wrapper
script (why would they?) so they get burnt by this umask problem. Their
pleas for help take bandwidth from the mailing list, makes for
disgruntled users, and creates bad karma for subversion.
In this case the admin even knew about the wrapper script, but because
the wrapper script and the binary had the same name he got burnt by the
search path.
I suggest a permanent fix:
a) "make install" should install the svn binary as /usr/bin/svn.real
b) "make install" should install the wrapper script as /usr/bin/svn
I can't think of any situation where the wrapper script would be a
hinderance. There's a slight overhead from the extra shell invocation
but it's all lost in the noise. If the admin wants the umask to be
something other than 002 they can edit the wrapper, but the default
should be 002 because that's what most admins want.
Sure, this is in the FAQ, but why have a FAQ when you can easily change
the defaults and avoid the questions in the first place?
> -----Original Message-----
> From: David Coppit [mailto:subversion@coppit.org]
> Sent: Tuesday, February 15, 2005 9:48 AM
> To: kfogel@collab.net
> Cc: users@subversion.tigris.org
> Subject: Re: What are the causes of DB corruption?
>
>
> On Mon, 14 Feb 2005 kfogel@collab.net wrote:
>
> > David Coppit <david@coppit.org> writes:
> >> All I'm having my developers do is check out a version from the
> >> repository using Eclipse and Subclipse. (There are no
> commits!) After
> >> a while, one of them tells me they get this error:
> >>
> >> svn: Berkeley DB error while opening environment for filesystem
> >> /scratch/coppit/svnroot/db:
> >> DB_RUNRECOVERY: Fatal error, run database recovery
> >>
> >> Sure enough, I get the same error when I try to do a checkout from
> >> the command line. svnadmin recover fails, as does svnadmin
> dump. Is
> >> there anything else I can tell you to help?
> >
> > Version numbers of everything, 'ls -lR' of repository,
> user/group you
> > run all commands that access the repository as, I guess.
> >
> > Are you accessing over NFS? http://, svn://, or file://?
>
> The problem was revealed in another thread: my svn wrapper
> was not being executed, so the permissions weren't being set.
> The developers were using
> svn+ssh, and some of them set their path in their .login,
> which doesn't
> get processed unless the shell is a login shell. As a result,
> they thought they were doing the right thing, but were
> actually running the system default, which wasn't protected.
> In the end I convinced the systems staff to wrap the svn in
> /usr/bin on the repository machine--it was the only way to be
> sure that the umask was set correctly.
>
> BTW, the paragraph in the SVN book that says that this is a
> Unix problem sounds like a cop-out to me. I don't see any
> scenario in which a DB corruption should be allowed. Instead,
> the SVN config should have the user specify the default
> repository group and umask. At the least it should prevent
> anyone who isn't set up correctly from corrupting the repository.
>
> David
>
> _____________________________________________________________________
> David Coppit david@coppit.org
> The College of William and Mary http://coppit.org/
>
> "Government big enough to supply everything you need is big
> enough to take everything you have ... The course of history
> shows that as a government grows, liberty decreases." --
> Thomas Jefferson
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Notice:
The information contained in this e-mail message and any attached files may
be confidential information, and may also be the subject of legal
professional privilege. If you are not the intended recipient any use,
disclosure or copying of this e-mail is unauthorised. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete all copies of this transmission together with any attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 15 00:22:48 2005