> -----Original Message-----
> From: Brian Mathis [mailto:bmathis@directedge.com]
>
> 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.
Yep, already fixed following an earlier email from someone. I missed the
umask setting, because I didn't read the section "Multiple Servers",
thinking I was running just one server. I had the wrong context for
"server".
> 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.
It appears to work right now, but we'll beat on it more before
transitioning.
> This brings me to the question of why are you using svn+ssh?
I thought I already said why. All the developers already have shell
accounts, so they can use the exact same login they've been using for
CVS, no need to set up a .htaccess file and use htpasswd. (I assume
there may be a way to get apache to login against the local user
accounts, but it was a trivial effort to do that with 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:
> 1. http
> 2. svnserve daemon
> 3. svn+ssh
> 4. file
>
> I can understand people who don't want to go through
> installing/reinstalling apache.
Actually, I did upgrade apache to apache 2.0.48 in the process, using
David Summers' rpms. Note that php no longer works now, which is the
next thing on my list to remedy... It isn't exactly a straight-forward
upgrade when you depend on apache for other things (like some of our
build system scripts that are php and currently non-functional --
shoulda set up Subversion on a different machine, at least
initially...).
> Instead of that, you should use svnserve as a daemon.
Definitely NOT.
> It ensures that every access is
> done on the repo using the same user and group.
Which is one of the primary reasons why I do NOT want to use it. I WANT
to have unique logins, both for security reasons and so we know exactly
who checked in what. And there's no transport-layer encryption that way.
> The only
> time svn+ssh and file should be used is if the repo is for a
> single user project.
See above. Transport-layer encryption is a big plus of svn+ssh. We've
got folks who work off-site. Yes, we could use https, but again, I want
to use the existing system user account info.
> This isn't really aimed at you, but everyone using svn+ssh or
> file access methods :)
No problem, but I think you've neglected to think of some of its
benefits. ;-)
> 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?
Choice is good!
--
Jarod C. Wilson, RHCE
System Administrator
VoiceBox Technologies
jarod@voicebox.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 4 22:10:09 2004