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

Re: svn_client_move7 and mixed-revisions

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Wed, 13 Mar 2013 11:09:02 +0000

"Bert Huijben" <bert_at_qqmail.nl> writes:

>> -----Original Message-----
>> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
>> Philip Martin
>> Sent: woensdag 13 maart 2013 10:42
>> To: Branko ─îibej
>> Cc: Mark Phippard; C. Michael Pilato; Philip Martin;
>> dev_at_subversion.apache.org
>> Subject: Re: svn_client_move7 and mixed-revisions
>> Branko ─îibej <brane_at_wandisco.com> writes:
>> > I have to agree with Mark. As long as we don't know how to track a
>> > mixed-revision move in all cases, then it's better to revert to
>> > copy+delete than to block the move. Ideally only for those parts of the
>> > move source that are actually out of date with regard to the repository,
>> > but I take it we haven't got that far yet.
>> Do we expose this feature in the JavaHL bindings?
> As long as we didn't switch JavaHL to svn_client_move7() we exposed the option as default via svn_client_move() upto svn_client_move6().
> But I think Brane switched JavaHL to enable the metadata only move. I would have to check the commit to see which value he enabled.

I exposed metadata_only but hard-coded allow_mixed_revisions=FALSE.

Certified & Supported Apache Subversion Downloads:
Received on 2013-03-13 12:09:54 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.