Greetings, Jim the Standing Bear!
> What were you referring to when you said "the worst way from
> administration point of view..."? the fact that these files were on a
> 775 permission? or the fact that these files were owned by different
> users? or the fact that we access our repository using svn+ssh?
The fact that you're using "svn+ssh". I think it was pretty clear from my
first quote. Sorry if that wasn't. The svn+ssh scheme is an administration
nightmare. Through svn+ssh, you accessing repository with connected user
credentials. Your error message points that you have(had) at least one process
accessing repository with credentials that not satisfy owner/umask of the
While working with https (for instance), repository is accessed by single user
- one that is assigned in Apache configuration (not always one that is Apache
runned from, there's a ways to impersonate a child process with different
credentials), reducing any authorization issues to the authentication times.
> If you are kind enough to go back to my original message and read it
> again, you will see that I was trying to find out why the lock file
> was owned by different user. what should the correct umask and
> permission be for this file? You failed to elaborate, and that is not
> helpful. It's the same as if some software crashed, and you say "it
> has a bad bug and take care of the bug".
Lock file was probably created initially when repository was established or
left behind when something nasty happened in it's life. Try disconnecting
repository, run necessary finishing tasks to make sure it's state consistent
and delete the file manually.
It does not "have a bug", it's just a thing that needs a great care, at times
turning into your personal little nightmare...
Andrey Repin (anrdaemon_at_freemail.ru) 19.08.2009, <14:02>
Sorry for my terrible english...
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-19 12:20:51 CEST