subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Levy <andy.l...@gmail.com>
Subject Re: SVN on fileshare - user cannot commit - cannot open file 'txn-current-lock'
Date Tue, 30 Aug 2011 01:59:10 GMT
On Mon, Aug 29, 2011 at 17:38, this_thread <cdail.forums@gmail.com> wrote:
>
>
> Ryan Schmidt-80 wrote:
>>
>>
>> On Aug 29, 2011, at 14:42, this_thread 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
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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 server running svnserve, or apache with mod_dav_svn. Don't
>> pursue doing this with a normal file server.
>>
>>
>
> I understand this is bad in the long run, but again, for emphasis:
>
> I am not an admin on the server in question
> I am not an admin on any machine that I can reasonably set up an svnserve
> daemon
> I do not have access to any servers beyond the file shares
>
> Therefore, for the TIME BEING until I can get the IT support folks to
> generate one for us:  is there any quick fix that will bandaid this for the
> time being?

It's bad in the short run too. If you're not the administrator, you
have zero assurance that your repositories are safe in their current
incarnation. One errant keystroke and it's all gone. Any bandaid you
put on will give you a false sense of security.

You need to get a proper server set up if you want to use Subversion safely.

Mime
View raw message