[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: What does txn-current-lock do?

From: Jim the Standing Bear <standingbear_at_gmail.com>
Date: Wed, 19 Aug 2009 12:29:20 -0400

Thank you Andrey, for the details. I wasn't the one who setup the
repository. For all I know, we've been using ssh to access CVS
before, and naturally ssh to svn now. I will talk to the
administrators to see if they are willing to get an apache going for
the svn, and also would be willing to do the credential impersonation
that you mentioned.

About the "bug" analogy - I didn't mean to say the lock was caused by
an svn bug - i was merely trying to make a point on how vague/general
statement could be difficult to interpret sometimes.

-- Jim

On Wed, Aug 19, 2009 at 6:15 AM, Andrey Repin<anrdaemon_at_freemail.ru> wrote:
> 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
> repository.
> 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...
> --
> WBR,
>  Andrey Repin (anrdaemon_at_freemail.ru) 19.08.2009, <14:02>
> Sorry for my terrible english...

Standing Bear Has Spoken
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-19 18:37:24 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.