2

I'm using TortoiseSVN to connect to a newly-created repository on my RHEL server. I did svnadmin create reponame as root to create the repository. I simply want to checkout the repository using TortoiseSVN so that I can add files to it.

I installed mod_dav_svn and can now connect and checkout the repository. On my local machine, I added files to the directory and tried to commit. However, TortoiseSVN now gives 

Can't open file '/subversion/langantiques/db/txn-current-lock': Permission
denied

How do I rectify this one?

Improve this question

3 Answers 3

Reset to default
3

If you created repo as root (with with umask, BTW) and later try to access repo with W action as local user with file:/// protocol (all mentioned parts in sentence are important) you have ordinary permission problem: user, under which you run svn process, have to have sufficient rights to work with repo. Chown or chmod or chgrp repo dir, as needed (I'm not a shaman to see your FS)

If your repo served by Apache - httpd process must have +r+w rights on repo

Improve this answer
6
  • Sounds like this is my issue. Would chmod 765 /subversion suffice?
    – SidC
    Dec 18, 2011 at 23:46
  • @SidC - as usual, "It depends". I don't know, which user do you use for access, which groups include this user. For multi-user environment (svn:// or svn+ssh://) I prefer join users in group and operate at group-permissions level. Can't say exact value, but 5 for "other" seems as extra-soft limitation
    – Lazy Badger
    Dec 18, 2011 at 23:55
  • I did chmod 777 /subversion and chown -R svnuser /subversion The issue still persists. How do I ensure that httpd process has r+w rights?
    – SidC
    Dec 19, 2011 at 1:54
  • I also tried chown -R www-data /subversion/* but received Invalid User. Is www-data named something else in RHEL?
    – SidC
    Dec 19, 2011 at 2:16
  • I don't know all distros. Try to find httpd-owner in /etc/ files (passwd and later groups?)
    – Lazy Badger
    Dec 19, 2011 at 3:26
2

You'll need something to serve the repository to remote nodes. There are three main options;

  1. svnserve

    This is a simple service that runs on port 3690 that allows access to your repository. It's pretty basic; it can enforce permissions settings but has no encryption for its network traffic (including passwords). You'd run the service (which is probably installed already on your server) and then run the checkout with an svn:// URL.

  2. WebDAV

    This option requires a web server - probably Apache, with the mod_dav_svn module. You can configure security (authentication and encryption) in the web server, as well as access controls; this is probably the most flexible of the options for this reason. You'd use an http:// or https:// URL to check this out.

  3. SSH

    This option uses the SSH setup that you've probably already got configured; in this way it gets good authentication and encryption. But, since it's using the linux users, you'll need to jump through some hoops to lock down any user that you want to have SVN access but not shell access. This also requires some wrangling to get the SSH connectivity working - last time I messed with it it involved feeding tortoise the plink.exe file from PuTTY. You'd access this with an svn+ssh:// URL.

Improve this answer
2
  • Mod_dav_svn is installed.
    – SidC
    Dec 18, 2011 at 20:23
  • Then can you provide the Apache configuration?
    – Shane Madden
    Dec 18, 2011 at 20:30
0

A couple of issues here -- there are some fairly intricate certificate/PVT key operations which while perfectly acceptable for plink/pageant may be going haywire. The SVN on the server can be perfectly OK and viable, yet the TortoiseSVN hookup craps out gloriously.

In theory, if the puTTY ssh config is working, you should be able to hook up via the inclusion of a 'load ' on the TortoisePlink command line you drop into the Settings->Network->SSH Shell entry. Notice the word 'should'.

I've tried every single step in every HowTo/FAQ/TortoiseSVN blurb out there (save some that require root privileges on the server in order to tamper with the /etc/svnserver parameters), and so far absolutely nothing works. The end result of about 2-1/2 weeks of effort is the message "Unable to connect to a repository at URL ...". Yet the SVN environment works like a dream, plink and putty work perfectly, and the SVN root path I pulled directly from the svn info line (minus the extraneous file:/// prefix).

I'm convinced there is something wrong that is so obvious that no one has thought to mention it in the literature.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .