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

Re: Locking issues

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-04-14 23:52:41 CEST

Ben Collins-Sussman <sussman@collab.net> writes:

>> Ben Collins-Sussman <sussman@collab.net> writes:
>>> 'svn info' is behaving just like any other command that needs to
>>> locate a repository object, isn't it? It's following copy-history
>>> just like everything else. Are you saying it shouldn't?
>> Perhaps you misunderstood, it doesn't matter what revision I pass as
>> -rX, if I don't use @head I don't see repository locks. So
>> $ svn info -rhead wcpath
>> doesn't show repository locks, but
>> $ svn info wcpath@head
>> does show them. Using a numeric revision
>> $ svn info wcpath@N
>> doesn't show repository locks, even when N is the same as head.
>> However
>> $ svn info -rN wcpath@head
>> does show repository locks even when N is not the same as head.
>> I find that behaviour surprsising, I would expect the peg revision to
>> matter when determining which URL to query, but I can't see why it
>> should affect whether lock information is requested.
> Hm, I guess you're right, that *does* seem like a bug. If you don't
> have time to investigate, can you file the bug, so that I'll remember
> to look at it tomorrow?

Can we agree on the behaviour? Earlier in this thread you suggested
'svn info -rN wcpath' should show repository locks, does that still
apply? Given the command 'svn info -rX wcpath@Y' which combination of
X and Y should show repository locks?

Another problem is that the svn_info_receiver_t callback gets an
svn_info_t which only contains one lock, so it's not possible for the
svn info command to show both the working copy and the repository
lock. Perhaps svn_info_t should be extended to allow both locks?

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 14 23:53:24 2005

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