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