> -Original Message-
> From: C. Michael Pilato [mailto:cmpil...@collab.net]
> Sent: maandag 8 april 2013 15:25
> To: Julian Foad
> Cc: Subversion Development
> Subject: Re: Consistency between 'update' and 'switch' APIs
>
> On 04/06/2013
On 04/06/2013 03:55 PM, Julian Foad wrote:
> Julian Foad wrote:
>
>> C. Michael Pilato wrote:
>>> [...] So I agree, both switch and update should carry the
>>> server-recognized meaning of 'ignore-ancestry' in both the client and
>>> RA layers.
>
> In r1465292 I added the 'ignore_ancestry' fla
Julian Foad wrote:
> C. Michael Pilato wrote:
>> [...] So I agree, both switch and update should carry the
>> server-recognized meaning of 'ignore-ancestry' in both the client
>> and RA layers.
In r1465292 I added the 'ignore_ancestry' flag to the RA 'update' APIs, for
consistency with 'switc
Philip Martin writes:
> Backwards compatibility. svn_repos_dir_delta had ignore-ancestry since
> 1.0, it was added in r845731, and switch operated with ignore-ancestry
> set false. r1087015 started making switch require history between the
Oops! Set true, i.e. ancestry was ignored.
> nodes, w
Julian Foad writes:
> Philip Martin wrote:
>> Michael Pilato" writes:
>
>>
>>> [Deferring further comment until we unearth the reasoning behind switch
>>> supporting --ignore-ancestry at all.]
>>
>> You added it in r1087015 as a backwards compatiblity switch when fixing
>> issue http://subve
Philip Martin wrote:
> Michael Pilato" writes:
>
>> [Deferring further comment until we unearth the reasoning behind switch
>> supporting --ignore-ancestry at all.]
>
> You added it in r1087015 as a backwards compatiblity switch when fixing
> issue http://subversion.tigris.org/issues/show_bug
"C. Michael Pilato" writes:
> [Deferring further comment until we unearth the reasoning behind switch
> supporting --ignore-ancestry at all.]
You added it in r1087015 as a backwards compatiblity switch when fixing
issue http://subversion.tigris.org/issues/show_bug.cgi?id=3848.
--
Certified & S
On 03/13/2013 10:15 PM, Julian Foad wrote:
> The interesting case here is a file replaced with an identical file:
> that's the only case where it's unchanged if ignoring ancestry but
> otherwise it's changed.
This may, in fact, be the only case that's interesting to our discussion.
But I trust you
C. Michael Pilato wrote:
> On 03/13/2013 01:36 PM, Julian Foad wrote:
>> The 'ignore_ancestry' parameter at the RA level is changing the way diffs
>> of replaced files are reported by the server. It is not the same as the
>> '--ignore-ancestry' flag that 'svn switch' accepts. 'svn switch
>>
On 03/13/2013 01:36 PM, Julian Foad wrote:
> The 'ignore_ancestry' parameter at the RA level is changing the way diffs
> of replaced files are reported by the server. It is not the same as the
> '--ignore-ancestry' flag that 'svn switch' accepts. 'svn switch
> --ignore-ancestry' causes libsvn_cli
C. Michael Pilato wrote:
> On 03/13/2013 11:37 AM, Julian Foad wrote:
>> svn_ra_do_update2(..., pool)
>> svn_ra_do_switch3(..., ignore_ancestry, ..., result_pool, scratch_pool)
>>
>> - switch3() is recently revised from switch2(), specifically to add the
>> 'ignore_ancestry' option to allow it to *
On 03/13/2013 12:37 PM, Branko Čibej wrote:
> Actually, if we're revving an API, it's just as valid to /remove/
> options as it is to add them. IMO.
> The backwards-compat behaviour can be encapsulated in the implementation.
>
> So, for example, we could go ahead and remove the ignore-ancestry opt
On 13.03.2013 17:29, Julian Foad wrote:
> I (Julian Foad) wrote:
>
> [...]
>> PROPOSAL
>>
>> - svn_ra_do_update2(): revise to svn_ra_do_update3(), add the
>> 'ignore_ancestry' option there too, and use two pools while we're at
>>
>> it. Track this change in the RA vtable 'update' method, proto
I (Julian Foad) wrote:
[...]
> PROPOSAL
>
> - svn_ra_do_update2(): revise to svn_ra_do_update3(), add the
> 'ignore_ancestry' option there too, and use two pools while we're at
>
> it. Track this change in the RA vtable 'update' method, protocols, etc.
>
> - svn_wc__get_switch_editor():
On 03/13/2013 11:37 AM, Julian Foad wrote:
> Intuitively I expect 'update' and 'switch' APIs to be the same except for
> their essential differences which are:
>
> - 'update' changes rev; 'switch' changes rev and URL.
>
> - 'switch' switches every node in the tree to a child of the same URL;
> 'u
15 matches
Mail list logo
