"Sak Wathanasin" <sw@[EMAIL PROTECTED]
> wrote in message
news:87b75843-b9de-4732-9886-8b29c54ab208@[EMAIL PROTECTED]
> On 15 May, 17:49, use...@[EMAIL PROTECTED]
(Woody) wrote:
>
>>> Anyway, if he can get stuff out of the repository but not update, it
>> > could be a permission or lock problem.
>>
>> It is undoubtadly some kind of permissions problem, but I know not
what.
>
> What connection method are you using? svnserve, ssh, DAV? With the
> first, the server process has to own the repository and everything
> underneath it. With the 2nd, the ssh user you use to connect
> (generally yourself) must have write perm to the repository dir and
> everything below it. With the last, the httpd process (apache/nobody/
> www/etc) must have write perm.
It is a svnserve connection. There is a user subversion and in its user
folder there is the repository.
Just to be on the safe side I did a chown -R subversion:staff repository,
but nothing changed.
I checked repository/conf/svnserve.conf and password-db points to
passwd
which contains all the username/passwords
Just to be on the safe side I put the username/passwords in svnserve as
well.
> What I generally do when setting up svn on a new system is to create a
> user & group svn/svn that owns the svn binaries and repositories. Then
> I add any users who need to access svn directly (either locally or via
> ssh) to the svn group, and also the httpd user (apache &c). Then I set
> the group sticky bit on the svn repository (chmod g+s). Finally, I
> modify the apachectl and svnserve initscript to set the umask so that
> files are created group-writeable. This allows users to access the svn
> repository using any combination of methods and not trip up one
> another.
I don't have the group (I used to on the old linux server.) I will change
that and see if ti helps
> If it is indeed a wedged DB, the SVN book goes into great detail on
> how to the recover from it (chp 5).
I will have a look at that, thanks
--
Woody
|
