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

Re: Consistency between 'update' and 'switch' APIs

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 13 Mar 2013 14:01:26 -0400

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_client to bypass a check that the switch
> source and destination URLs have a common ancestor before starting the
> switch.
>
> The '--ignore-ancestry' flag also sets this 'ignore_ancestry' parameter
> in the RA call to cause the server to send diffs of replaced files in a
> different way, but that is a secondary effect. It controls whether the
> diff of a file that happens to exist at the same relative path is
> reported as text-modify or as delete-and-add, and so affects whether and
> how conflicts are raised if the user had local mods.
>
> It is this 'do diffs as text-mods' meaning that we should make
> consistently available to both 'update' and 'switch' at the RA level.

Ah, yes, I forgot about the multiple meanings of this flag in the different
layers. So I agree, both switch and update should carry the
server-recognized meaning of 'ignore-ancestry' in both the client and RA
layers. (Sorry for the mental lapse.)

This may be a bit of a sidebar, but: Does svn_ra_do_status() need the same
treatment? I mean, to the degree that 'svn status -u' is supposed to be a
particularly shaped type of dry-run update, does it also need support for
the --ignore-ancestry flag?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2013-03-13 19:02:01 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.