What you are seeing is 100%, without a doubt, a permissions problem.
You were accessing the repo using your account, and when you tried a
different account it blew up.
Having everyone in the svn group is not enough. The repo directory must
also be g+s, and also owned by the svn group. All files must be g+w,
and also umask for everyone must be 002. Even with all that, it might
not work right.
This brings me to the question of why are you using svn+ssh? Out of the
4 access methods you have to choose from, you've chosen (IMO), the 3rd
most desirable one. They are, in order of desireability:
2. svnserve daemon
I can understand people who don't want to go through
installing/reinstalling apache. Instead of that, you should use
svnserve as a daemon. It ensures that every access is done on the repo
using the same user and group. The only time svn+ssh and file should be
used is if the repo is for a single user project.
This isn't really aimed at you, but everyone using svn+ssh or file
access methods :)
It really makes no sense to me that you could have so many different
ways to access the repo. If you look at any other multiuser database,
they all have 1 frontend that is the interface to the disk files.
Mysql, postgres, ldap, etc... Why is svn different?
Jarod Wilson wrote:
>Hi all, first post, be gentle...
>A little history: I work for a mixed Windows and Linux shop (mostly
>Windows). We've been using CVS for quite some time, but several
>developers complain about its shortcoming, especially with the recent
>restructuring of our source tree, which of course blew away all the
>history on many files. Said developers are partial to Perforce, but we
>are on a bit of a budget. I've done some homework, and Subversion looks
>like the ticket for us.
>However, what looks good on paper isn't translating to production very
>well. I've got Subversion 1.0 up and running from David Summer's rpms on
>a Red Hat Linux 7.2 box (which is also our CVS server), with the
>intention of using predominantly svn+ssh for access, since everyone
>already has a shell account on the machine. I was able to import our
>source tree just fine from the local machine after creating the repo,
>check out, check in, etc. When we moved over to a Windows box using
>TortoiseSVN, all hell broke loose. Basically, at least one in every two
>actions taken resulted in db errors, with a message telling us to run
>Fast forward a bit, I nuked the repo, recreated it, then did an import
>from a Windows box via TortoiseSVN. Everything looked fine. I even got
>two machines set up, both checking in, checking out, diffing, repo
>browsing, etc., simultaneously and everything (one box running Windows
>2003 Server, one running Windows 2000 Pro). Excellent, I thought.
>However, note that both machines were using my login. Then I went over
>to another developer's machine, tried his login, and got db errors
>(can't recall if they were immediate, or after a number of files had
>been checked out). Running svnadmin recover on our repo isn't even
>recovering it now. (I haven't tried using db_runrecovery directly yet).
>Now, I do have both a primary user and group defined for Subversion (u/g
>svn/svn), and all developers are members of the svn group, so I don't
>think I have any permissions issues, but I've been fighting this thing
>for more than a week... I'm about to try a newer BerkeleyDB (4.2, versus
>4.0 on our RHL7.2 machine) and Subversion on a Fedora Core 2 machine to
>see if it is any better, but if anyone has any insight into what my
>problem might be, I'd appreciate the help! I know everyone will REALLY
>like Subversion over CVS, once we get it running in a stable fashion.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Mar 4 21:39:44 2004