You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by SteveKing <st...@gmx.ch> on 2005/04/13 16:57:01 UTC

How to find out if I own a lock?

Hi,

I was wondering if there's an easy way to find out if a lock on a file 
is owned by the one owning the working copy (i.e. if the file isn't 
readonly but has a lock owner assigned to it).
I know I could just do an svn_client_status2() and then check if the 
file is readonly, but that's another filestat call which 
svn_client_status2() already does too.
Maybe there's something in the lock UID which can be used for that?

If not, then may I suggest to add another entry to the svn_wc_entry_t 
structure which indicates if a file is readonly?


Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by Barry Scott <ba...@barrys-emacs.org>.
On Apr 13, 2005, at 20:17, C. Michael Pilato wrote:

> Ben Collins-Sussman <su...@collab.net> writes:
>
>> Ah, so it seems that you want to implement inverse logic.
>>
>> The logic should be:
>>
>>      if (versioned && has-no-lock-token)
>>        if (svn:needs-lock is present)
>>          show "should lock" overlay
>>
>> But you want to do
>>
>>      if (versioned && has-no-lock-token)
>>        if (readonly)
>>          show "should lock" overlay.
>>
>> But as cmpilato pointed out, those logics aren't equivalent.  A file
>> can be read-only for other reasons besides the existence of
>> svn:needs-lock.  Is this going to cause problems?  I forsee lots of
>> false positives here.  Is it worth the performance tradeoff?
>
> Steve, is there any way you can quantify the performance hits we're
> talking about?  Tweak TSVN to do the property checks, and see how it
> really affects things, ya know?

This is yet another problem that the depth API will help solve.

Here are the performance number I did back in oct 2004.
I'd love to know if TSVN sees similar performance.

On Oct 30, 2004, at 11:53, Barry Scott wrote:

> I have created a test program test_propval.cpp in
> http://svn.collab.net/repos/pysvn/trunk/pysvn/Extension/Patches
>
> I run the program in the Patches directory with the command line
>
> test_propval readme.txt 100
>
> Running on a 600MHz Mandrake 9.2 system I get:
>
>         Time for 100 calls 170ms
>         Time for 1 call 1ms
>
> Running on a 1GHz Windows XP SP1 systems with Norton
> anti-virus enabled:
>
>         Time for 100 calls 2423ms
>         Time for 1 call 24ms
>
> Running on a 1GHz Windows XP SP1 systems with Norton
> anti-virus disabled:
>
>         Time for 100 calls 1392ms
>         Time for 1 call 13ms


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by SteveKing <st...@gmx.ch>.
C. Michael Pilato wrote:
> Steve, is there any way you can quantify the performance hits we're
> talking about?  Tweak TSVN to do the property checks, and see how it
> really affects things, ya know?

I don't have to do property checks first to see the performance 
degradation. Just compare the following:

To show a versioned folder in explorer, TSVN does one 
svn_client_status() call and then caches that data. Explorer asks the 
status of each file individually, which TSVN then returns from the 
cache. Now, we had that cache time out after about 10 seconds. For big 
working copies, that wasn't enough because it took longer to show that 
folder in explorer.
Now imagine if I have to ask *every* file for its svn:needs-lock 
property - that would mean for each file about three file access calls 
(don't know for sure, but I think that API accesses at least the entries 
file, checks if the .svn folder is present, ...).
That would at least double the time it takes now for just the 
svn_client_status() call! And I think it will take even longer, since 
svn_client_status() only has to read the entries file once, not once for 
every file.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:

> Ah, so it seems that you want to implement inverse logic.
> 
> The logic should be:
> 
>      if (versioned && has-no-lock-token)
>        if (svn:needs-lock is present)
>          show "should lock" overlay
> 
> But you want to do
> 
>      if (versioned && has-no-lock-token)
>        if (readonly)
>          show "should lock" overlay.
> 
> But as cmpilato pointed out, those logics aren't equivalent.  A file
> can be read-only for other reasons besides the existence of
> svn:needs-lock.  Is this going to cause problems?  I forsee lots of
> false positives here.  Is it worth the performance tradeoff?

Steve, is there any way you can quantify the performance hits we're
talking about?  Tweak TSVN to do the property checks, and see how it
really affects things, ya know?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by SteveKing <st...@gmx.ch>.
Philip Martin wrote:
> SteveKing <st...@gmx.ch> writes:
> 
> 
>>But what about having the filestat information in the svn_wc_entry_t
>>struct returned by svn_client_status()?
> 
> 
> apr_finfo_t is 84 bytes on a 32-bit machine, that would be quite a
> large increase in the size of svn_wc_entry_t which is currently 124
> bytes.  (I see we still have all the new lock stuff in svn_wc_entry_t,
> didn't we agree to drop everything but the lock token?)
> 
> Perhaps we could put it into svn_wc_status2_t?

124 bytes? That can't be right. Maybe the sizeof() is 124 bytes, but the 
whole struct is much larger already. There are several entries which are 
strings (name, url, uuid, ...). So I don't think another entry
apr_finfo_t * fileinfo
would increase the size of that struct that much.

>>That would help TSVN a lot (performance wise) - I guess you know
>>that Windows isn't as fast with those calls as Linux, there were
>>some reports before about timing of 'svn st' and 'svn ci' for Linux
>>and Windows on this list...
> 
> I find it odd that one more stat call would make that much difference,
> because svn_client_status itself is so ineffecient.  It stats each
> versioned file 5 times, with a further 7 stats on the properties
> files.  Plus it reads the entire working properties file for each
> versioned file.  Does it really matter if TSVN makes one more stat?

Every filestat call matters. Basically, you can assume that the time an 
svn_client_status2() call takes is spent by file access. The little time 
the function needs for calculating stuff doesn't matter much, and that 
time get's smaller with faster processors. But the time for file 
accesses can't be made faster with faster processors.
So, the 13 stats for svn_client_status() plus one TSVN would need: 
that's an increase of 7%!

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by Philip Martin <ph...@codematters.co.uk>.
SteveKing <st...@gmx.ch> writes:

> But what about having the filestat information in the svn_wc_entry_t
> struct returned by svn_client_status()?

apr_finfo_t is 84 bytes on a 32-bit machine, that would be quite a
large increase in the size of svn_wc_entry_t which is currently 124
bytes.  (I see we still have all the new lock stuff in svn_wc_entry_t,
didn't we agree to drop everything but the lock token?)

Perhaps we could put it into svn_wc_status2_t?

> That would help TSVN a lot (performance wise) - I guess you know
> that Windows isn't as fast with those calls as Linux, there were
> some reports before about timing of 'svn st' and 'svn ci' for Linux
> and Windows on this list...

I find it odd that one more stat call would make that much difference,
because svn_client_status itself is so ineffecient.  It stats each
versioned file 5 times, with a further 7 stats on the properties
files.  Plus it reads the entire working properties file for each
versioned file.  Does it really matter if TSVN makes one more stat?

$ strace svn st tools/dev 2>&1 | grep stress.pl
lstat64("tools/dev/stress.pl", {st_mode=S_IFREG|0755, st_size=15194, ...}) = 0
lstat64("tools/dev/stress.pl", {st_mode=S_IFREG|0755, st_size=15194, ...}) = 0
lstat64("tools/dev/stress.pl", {st_mode=S_IFREG|0755, st_size=15194, ...}) = 0
stat64("tools/dev/.svn/props/stress.pl.svn-work", {st_mode=S_IFREG|0444, st_size=61, ...}) = 0
stat64("tools/dev/.svn/props/stress.pl.svn-work", {st_mode=S_IFREG|0444, st_size=61, ...}) = 0
stat64("tools/dev/.svn/prop-base/stress.pl.svn-base", {st_mode=S_IFREG|0444, st_size=61, ...}) = 0
stat64("tools/dev/.svn/props/stress.pl.svn-work", {st_mode=S_IFREG|0444, st_size=61, ...}) = 0
stat64("tools/dev/.svn/prop-base/stress.pl.svn-base", {st_mode=S_IFREG|0444, st_size=61, ...}) = 0
lstat64("tools/dev/.svn/props/stress.pl.svn-work", {st_mode=S_IFREG|0444, st_size=61, ...}) = 0
lstat64("tools/dev/.svn/props/stress.pl.svn-work", {st_mode=S_IFREG|0444, st_size=61, ...}) = 0
open("tools/dev/.svn/props/stress.pl.svn-work", O_RDONLY) = 3
lstat64("tools/dev/stress.pl", {st_mode=S_IFREG|0755, st_size=15194, ...}) = 0
lstat64("tools/dev/stress.pl", {st_mode=S_IFREG|0755, st_size=15194, ...}) = 0

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by SteveKing <st...@gmx.ch>.
Ben Collins-Sussman wrote:
>> I know those logics aren't equivalent. But Subversion would have 
>> problems with versioned readonly files if they don't have the 
>> svn:needs-lock property on them, right? I mean, versions < 1.2 at 
>> least will error out if such a readonly file has to be changed by an 
>> update. So I don't think that there are any users out there who have 
>> files set readonly themselves for whatever reason.
> 
> Ooh, good point.  You've convinced me.  I guess the new overlay needs to 
> be documented carefully:  it doesn't mean that svn:needs-lock is 
> present, it means that the file is read-only.  And if the file is 
> read-only, that *probably* means that it should be locked before editing.

Sure! We haven't really started on the docs for 1.2 yet, but as soon as 
we implemented most of those features in TSVN we will start with the 
docs - it doesn't make much sense to write the docs before we know how 
TSVN will handle these things exactly.

But what about having the filestat information in the svn_wc_entry_t 
struct returned by svn_client_status()? That would help TSVN a lot 
(performance wise) - I guess you know that Windows isn't as fast with 
those calls as Linux, there were some reports before about timing of 
'svn st' and 'svn ci' for Linux and Windows on this list...

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 13, 2005, at 2:24 PM, SteveKing wrote:

> I know those logics aren't equivalent. But Subversion would have 
> problems with versioned readonly files if they don't have the 
> svn:needs-lock property on them, right? I mean, versions < 1.2 at 
> least will error out if such a readonly file has to be changed by an 
> update. So I don't think that there are any users out there who have 
> files set readonly themselves for whatever reason.

Ooh, good point.  You've convinced me.  I guess the new overlay needs 
to be documented carefully:  it doesn't mean that svn:needs-lock is 
present, it means that the file is read-only.  And if the file is 
read-only, that *probably* means that it should be locked before 
editing.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by Michael Brouwer <mi...@tlaloc.net>.
Why not display the filenames in the browser immediately, and fetch  
the properties (or update whatever else needs updating) for just the  
files being displayed currently, which is not going to be more than  
about 100 at a time, in a background thread and update the display  
when you get the results back?  This allows for a snappy UI and it  
being up to date.  You could show a little spinning wheel or  
something when you are fetching stuff in the background.

Michael

On Apr 13, 2005, at 12:40 PM, SteveKing wrote:

> Peter N. Lundblad wrote:
>
>> Can't you cache svn:needs-lock? It will need to be invalidated  
>> only when
>> the last-committed-rev changes for the file.
>>
>
> Sure. But it's the time until that property is in the cache that's  
> important. It has to be read at least once for each file, and it  
> has to be read when the user wants to show the contents of a folder  
> in the explorer - that would make the explorer hang for several  
> seconds (at least the first time, when the cache doesn't have that  
> information yet).
> Users won't accept that...
>
> Stefan
>
> -- 
>        ___
>   oo  // \\      "De Chelonian Mobile"
>  (_,\/ \_/ \     TortoiseSVN
>    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
>    /_/   \_\     http://tortoisesvn.tigris.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by SteveKing <st...@gmx.ch>.
Peter N. Lundblad wrote:
> Can't you cache svn:needs-lock? It will need to be invalidated only when
> the last-committed-rev changes for the file.

Sure. But it's the time until that property is in the cache that's 
important. It has to be read at least once for each file, and it has to 
be read when the user wants to show the contents of a folder in the 
explorer - that would make the explorer hang for several seconds (at 
least the first time, when the cache doesn't have that information yet).
Users won't accept that...

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 13 Apr 2005, SteveKing wrote:

> Ben Collins-Sussman wrote:
>
> And yes: performance is *the* big issue here. We already had a lot of
> complaints about performance with TSVN in the past. We did everything to
> improve that performance by caching whatever is cacheable to reduce
> calls to svn_client_status() and filestat calls. So I don't like the
> idea of now adding filestat calls again which will decrease performance
> a lot (in fact, a filestat call is so expensive we got rid of them in
> our cache almost completely - we rather have the cache contain outdated
> data for some time than doing those calls).
>
Can't you cache svn:needs-lock? It will need to be invalidated only when
the last-committed-rev changes for the file.

Regards,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by SteveKing <st...@gmx.ch>.
Ben Collins-Sussman wrote:

> Ah, so it seems that you want to implement inverse logic.
> 
> The logic should be:
> 
>     if (versioned && has-no-lock-token)
>       if (svn:needs-lock is present)
>         show "should lock" overlay
> 
> But you want to do
> 
>     if (versioned && has-no-lock-token)
>       if (readonly)
>         show "should lock" overlay.
> 
> But as cmpilato pointed out, those logics aren't equivalent.  A file can 
> be read-only for other reasons besides the existence of svn:needs-lock.  
> Is this going to cause problems?  I forsee lots of false positives 
> here.  Is it worth the performance tradeoff?

I know those logics aren't equivalent. But Subversion would have 
problems with versioned readonly files if they don't have the 
svn:needs-lock property on them, right? I mean, versions < 1.2 at least 
will error out if such a readonly file has to be changed by an update. 
So I don't think that there are any users out there who have files set 
readonly themselves for whatever reason.

And yes: performance is *the* big issue here. We already had a lot of 
complaints about performance with TSVN in the past. We did everything to 
improve that performance by caching whatever is cacheable to reduce 
calls to svn_client_status() and filestat calls. So I don't like the 
idea of now adding filestat calls again which will decrease performance 
a lot (in fact, a filestat call is so expensive we got rid of them in 
our cache almost completely - we rather have the cache contain outdated 
data for some time than doing those calls).

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 13, 2005, at 1:59 PM, SteveKing wrote:

> Ben Collins-Sussman wrote:
>> The sentence you just wrote above -- "users could see that a file 
>> needs to be locked" -- is *exactly* the reason the svn:needs-lock 
>> property exists.  If you're thinking about creating a new icon 
>> overlay that means, "you should lock this file before editing", then 
>> you should make it into a 1-to-1 correspondence with the existence of 
>> svn:needs-lock.
>> So your criteria for showing this new overlay would be:
>>    - the file is versioned && file has svn:needs-lock
>> That's all you need.
>
> I know that. But: reading the properties of a file is an expensive 
> function call (performance wise, if you have to do it for many, many 
> files very fast). So that's not really an option for TSVN because 
> overlays can't take long to show them, or the explorer would slow down 
> remarkably.
>

Ah, so it seems that you want to implement inverse logic.

The logic should be:

     if (versioned && has-no-lock-token)
       if (svn:needs-lock is present)
         show "should lock" overlay

But you want to do

     if (versioned && has-no-lock-token)
       if (readonly)
         show "should lock" overlay.

But as cmpilato pointed out, those logics aren't equivalent.  A file 
can be read-only for other reasons besides the existence of 
svn:needs-lock.  Is this going to cause problems?  I forsee lots of 
false positives here.  Is it worth the performance tradeoff?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by SteveKing <st...@gmx.ch>.
Ben Collins-Sussman wrote:
> The sentence you just wrote above -- "users could see that a file needs 
> to be locked" -- is *exactly* the reason the svn:needs-lock property 
> exists.  If you're thinking about creating a new icon overlay that 
> means, "you should lock this file before editing", then you should make 
> it into a 1-to-1 correspondence with the existence of svn:needs-lock.
> 
> So your criteria for showing this new overlay would be:
> 
>    - the file is versioned && file has svn:needs-lock
> 
> That's all you need.

I know that. But: reading the properties of a file is an expensive 
function call (performance wise, if you have to do it for many, many 
files very fast). So that's not really an option for TSVN because 
overlays can't take long to show them, or the explorer would slow down 
remarkably.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 13, 2005, at 1:42 PM, SteveKing wrote:
>
> I wanted to show the readonly state if:
> - the file is readonly
> - it's versioned
> - the lock owner is empty (i.e. it's not locked in the wc)
>
> That way users could immediately see that such a file needs to be 
> locked before they can edit it.


The sentence you just wrote above -- "users could see that a file needs 
to be locked" -- is *exactly* the reason the svn:needs-lock property 
exists.  If you're thinking about creating a new icon overlay that 
means, "you should lock this file before editing", then you should make 
it into a 1-to-1 correspondence with the existence of svn:needs-lock.

So your criteria for showing this new overlay would be:

    - the file is versioned && file has svn:needs-lock

That's all you need.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2005-04-13 at 14:42, SteveKing wrote:
> I don't know how much work this would cause to implement it, but from my 
> point of view it's just another entry in that struct, filled by the same 
> subfunction which does the filestat call - if that function isn't called 
> for some reason leave that entry empty or NULL.

I think our main concern would be that, for big directories, adding a
bunch of data to svn_wc_entry_t would result in using a lot more memory
for the entries cache.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by SteveKing <st...@gmx.ch>.
C. Michael Pilato wrote:

>>So now my request for an enhancement to the svn_wc_entry_t struct: a
>>boolean value indicating that an entry is readonly. Since
>>svn_client_status2() already opens those files to check the filedates,
>>that information is 'for free'. Otherwise I have to do a filestat call
>>for every file again, which is very bad (performance wise).
> 
> Could you explain again why you need to know the read-only status?
> You do realize that not all files locked by (someone) have their
> read-only bits set, right?  TortoiseSVN being all Explorer-plugin-y
> and stuff, seems that just read-only-ness (for read-only-ness's sake)
> is something folks can get via other routes.

I wanted to show the readonly state if:
- the file is readonly
- it's versioned
- the lock owner is empty (i.e. it's not locked in the wc)

That way users could immediately see that such a file needs to be locked 
before they can edit it.

But as the discussion about this on the TSVN list goes, it's not that 
important for users. At least not right now, maybe it will be once they 
can play around with the locking feature more.

But the readonly flag is only one thing I'd like to get from 
svn_client_status2(). I mean that function already does a filestat, so I 
think it would be a good idea if it would return the whole filestat 
information too (to avoid having clients do additional filestat calls).
I found myself in need of information from a filestat call quite often 
(e.g. readonly flag, last-changed-time, last-accessed-time, filesize, 
...) and whenever I need that information I have to do filestat calls again.

So even if TSVN doesn't implement such an overlay, I still think it 
would be a good idea to return that information in the svn_wc_entry_t 
structure too. Clients which don't need that information can ignore it, 
but those who need it can reduce the filestat calls a lot.

I don't know how much work this would cause to implement it, but from my 
point of view it's just another entry in that struct, filled by the same 
subfunction which does the filestat call - if that function isn't called 
for some reason leave that entry empty or NULL.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by "C. Michael Pilato" <cm...@collab.net>.
SteveKing <st...@gmx.ch> writes:

> So to check if I got it right this time:
> - if the svn_lock_t structure is filled in in a working copy, *that*
> working copy owns the lock.
> - if someone else has a file locked, it's not possible without
> contacting the repository to find that out (updates don't update that
> information in the wc - that's not stored in the wc at all).

That is correct.

> So now my request for an enhancement to the svn_wc_entry_t struct: a
> boolean value indicating that an entry is readonly. Since
> svn_client_status2() already opens those files to check the filedates,
> that information is 'for free'. Otherwise I have to do a filestat call
> for every file again, which is very bad (performance wise).

Could you explain again why you need to know the read-only status?
You do realize that not all files locked by (someone) have their
read-only bits set, right?  TortoiseSVN being all Explorer-plugin-y
and stuff, seems that just read-only-ness (for read-only-ness's sake)
is something folks can get via other routes.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by SteveKing <st...@gmx.ch>.
Ben Collins-Sussman wrote:

>> I was wondering if there's an easy way to find out if a lock on a file 
>> is owned by the one owning the working copy (i.e. if the file isn't 
>> readonly but has a lock owner assigned to it).
> 
> 
> svn_client_info() returns an svn_lock_t inside the svn_info_t 
> structure.  If a lock-token is attached to the working-copy file, then 
> information about the lock is in that svn_lock_t structure.  Does that 
> help?

Not really. The svn_wc_entry_t structure already contains that 
information. But that's not what I'm looking for.

Seems I didn't read the locking notes enough. I thought that when doing 
'svn up' the lock information is stored in the wc (so the user can see 
which files are locked by which user). But as I just tested with 
file:/// that's not the case.

So to check if I got it right this time:
- if the svn_lock_t structure is filled in in a working copy, *that* 
working copy owns the lock.
- if someone else has a file locked, it's not possible without 
contacting the repository to find that out (updates don't update that 
information in the wc - that's not stored in the wc at all).

So now my request for an enhancement to the svn_wc_entry_t struct: a 
boolean value indicating that an entry is readonly. Since 
svn_client_status2() already opens those files to check the filedates, 
that information is 'for free'. Otherwise I have to do a filestat call 
for every file again, which is very bad (performance wise).

The svn:needs-lock property doesn't help here either:
- it takes even more time to read that property than to check the 
readonly flag of a file
- the property is there even if the working copy itself has the lock

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How to find out if I own a lock?

Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 13, 2005, at 11:57 AM, SteveKing wrote:

> Hi,
>
> I was wondering if there's an easy way to find out if a lock on a file 
> is owned by the one owning the working copy (i.e. if the file isn't 
> readonly but has a lock owner assigned to it).

svn_client_info() returns an svn_lock_t inside the svn_info_t 
structure.  If a lock-token is attached to the working-copy file, then 
information about the lock is in that svn_lock_t structure.  Does that 
help?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org