On Mon, Aug 29, 2011 at 3:42 PM, this_thread <cdail.for...@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.
