subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: svn_client_infox
Date Mon, 17 Mar 2014 11:12:08 GMT


> -----Original Message-----
> From: Steenwyk, Chris [mailto:chris.steenwyk@gentex.com]
> Sent: vrijdag 14 maart 2014 18:20
> To: users@subversion.apache.org
> Subject: svn_client_infox
> 
> Hi,
> 
> I recently upgraded from SVN 1.7.10 to 1.8.8. In the API I was using the
> "svn_client_info2" function to obtain the lock state of files in the
> "svn_info_t" struct. I see that in 1.8.8 this function is deprecated, but
it calls
> "svn_client_info3" and still works. The issue I am bumping into is that
the
> documentation states that the "lock" member of "svn_info_t" is "An
> exclusive lock, if present.". In version 1.7.10 I could rely on this value
being
> NULL if there was no lock on the file, or valid if there was a lock. With
version
> 1.8.8 I am now seeing the lock member being valid, but the contents are
all
> left NULL (e.g svn_client_info3->lock != NULL but svn_client_info3->lock-
> >owner == NULL). This behavior seems to happen if I query the server for
> the lock status. If I query the complete path to a working copy, the info
> function behaves as expected with the "lock" member being NULL.
> 
> I looked through the release notes and error reports but didn't see this.
I also
> tried to locate the change in code that may have caused this but I wasn't
able
> to fund it.
> 
> Any help would be appreciated. For a temporary workaround I changed my
> code to check that lock and lock->owner are defined.

This behavior change is caused by switching from the ra_neon to the ra_serf
library; not a specific behavior change. 

I fixed this behavior in serf on trunk and nominated the patch for 1.8.9,
but for the time being I would recommend checking for lock and lock->token,
to see if it is realy valid.

The token is what makes a lock 'a lock', if that value is NULL it is clearly
not a lock.

(The author could in theory be empty, for security reasons)

	Bert



Mime
View raw message