On Mon, Aug 29, 2011 at 3:42 PM, this_thread <cdail.forums_at_gmail.com> wrote:
>
> I have several SVN repositories on an Windows network fileshare. The user has
> full control, read, write, and just about every other permission that can be
> added. When trying to commit he gets the error:
>
> Can't open file '//fileshare/svnrepos/projectname/db/txn-current-lock':
> Permission denied
Are *you* the "user"? And can you oopen up hte repositories and make
sure that they files, especially the "db" subdirectories, have write
access for you and other users who might need direct such access?
Also, with this setup, there's no strong reason you can't run a
webserver for Subversion on your desktop, on top of the fileshare.
This would channel all access to relevant files through the webserver
as the designated user, and make file ownership a lot easier to
manage. It also helps assure that the server is an up-to-date version
of Subversion, and not an older client that may have bugs or
incompatibilities wiht a current repository.
> It's being accessed via file:///, which I know is badbadterrible but I don't
> know how else to set it up given I am not an admin and this fileshare is all
> we have available.
See above. You can run Apache on top of the file share, as a user with
write access to the repo, and control access with Apache based
authorization.
> I've dug around a bit and been told I need to be using snvserve, but we
> don't have svnserve running on the remote share. I can try executing it from
> my machine but it just hangs, never prints anything. I can't install or
> really do much to the remote machine.
svnserve is not popular for various reasons. You can run svnserve or
Apache on any host with fileshare access, and that
> I know it would be better to have this on an svn server, but to get this up
> and running in the mean time, what do I need to look at? (And ideally, how
> could I get an svnserver going? Would I need to talk to some of the admins
> that take care of that share?) Short term just getting it to where he can
> commit now, long term being the svnserver..
You need a host to run ther server on, even if it's also doing other
tasks, and that host and the user running the svnserve or Apache
daemons needs write access to the "db" subdirectories of your
repositories. This is the key to providing "file://" access: whatever
user or users you want to have write access, need that access to the
"db" subdirectory. It's hazardous to provide "file://" access
especially because errors by users can delete or even corrupt the
repository in spectacularly messy fashion. Worse in terms of
Subversion's usage model, ordinary users can alter checked-in
revisions behind your back, and you'd better *believe* there are
people who think this is OK to do.
Received on 2011-08-30 14:23:39 CEST