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

Locking problem with the putfile.py from tools/examples

From: Sean McGrath <sean.mcgrath_at_propylon.com>
Date: Tue, 30 Dec 2008 15:02:28 -0800 (PST)

Hello there,

I am trying to get two standalone Python scripts together for locking and unlocking files in a repository. The idea is for these to work directly on the repository - not on a working copy. The are analogous to putfile.py from tools/examples in that respect.

Using Kevin Gillette's notes on [1] I have created a lockfile.py.

The problem is that once a file is locked, I can no longer use putfile.py to update the file using the same identity that holds the lock.

The exception thrown is svn.core.SubversionException: (
 "Cannot verify lock on path '/testing'; no username available", 160034)

Kevin Gillette's notes on [1] speak about associating a username with the repos pointer like this:

   access = fs.create_access(username)
   fs.set_access(fs_ptr, access)

Adding these to putfile.py before creating the transaction improves/changes matters. The exception changes to:
 svn.core.SubversionException: (
 Cannot verify lock on path '/testing'; no matching lock-token available)

I'm guessing that the issue comes down to putfile.py having to provide a lock token as well as an identity (something that a working copy client would do automatically.)

Does this sound plausible? Is there a mechanism through the Python APIs for me to provide the lock token?

I have a self contained zip that illustrates the problem if anybody is interested.

Is this a bit low level for the users list? Should I move this to dev?


[1] http://jtauber.com/python_subversion_binding/


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-01-27 23:09:54 CET

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.