is it a valid set_path report?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

is it a valid set_path report?

Dmitry Pavlenko-2
Hello Subversion community,
I have a question regarding set_path / update behaviour.

Suppose I want to use libsvn_ra library I report my ("virtual") working copy
as

  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!
--
Dmitry Pavlenko,
TMate Software


Reply | Threaded
Open this post in threaded view
|

Re: is it a valid set_path report?

Julian Foad-5
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.

--
- Julian
Reply | Threaded
Open this post in threaded view
|

Re: is it a valid set_path report?

Branko Čibej
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