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

Re: is it a valid set_path report?

From: Branko Čibej <brane_at_apache.org>
Date: Tue, 6 Nov 2018 23:32:25 +0100

On 06.11.2018 18:19, Julian Foad wrote:
> Dmitry Pavlenko wrote:
>> set_path "" 6 infinity
>> set_path "directory" 6 infinity
>> set_path "directory/subdirectory" 5 infinity
>> finish_report
>>
>> and run svn_ra_do_update3() with revision=6 to get changes of
>> "directory/subdirectory" between r5 and r6.
>>
>>
>> My question is whether such a report is valid or not.
>>
>>
>> I've found a citation from svn_ra.h
>> * This will *override* any previous set_path() calls made on parent
>> * paths. @a path is relative to the URL specified in svn_ra_open4().
>> but from it cannot understand if I can override parent set_path with the same
>> revision number and the same depth parameter.
>>
>> When I tried to find out what SVN command line client does in a similar
>> scenario, and it always does
>>
>> set_path "" 6 infinity
>> set_path "directory/subdirectory" 5 infinity
>> finish_report
>>
>> e.g. it reports a working copy in a more clever way. But I still want to
>> understand whether the first report is valid. Thanks!
> Hello Dmitry. In my interpretation, the documentation implies both reports are valid. APIs generally always allow a no-op of setting a value to its current value; only if that were NOT allowed then I would expect it to be explicitly documented and tested.

The semantics of the WC state reporter are such that both of the reports
you mention above are valid and have exactly the same meaning. Both
should instruct the server to produce exactly the same update, since
they describe the same WC state. (If they don't, please do let us know,
as that would be a bug in our repository implementation).

-- Brane
Received on 2018-11-06 23:32:34 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.