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

Re: Issue #4476 - Mergeinfo containing r0 makes svnsync and svnadmin dump fail

From: Branko Čibej <brane_at_wandisco.com>
Date: Wed, 17 Dec 2014 19:55:51 +0100

On 17.12.2014 17:13, Julian Foad wrote:
> Branko Čibej wrote:
>> On 17.12.2014 15:52, Julian Foad wrote:
>>> In http://svn.apache.org/r1646250 I committed a version that also works by
>>> textual substitution, but (hopefully) without the above-mentioned issues. This
>>> makes svnsync remove r0 references before trying to commit.
>> Does this mean that a dump/load or sync from a repository with r0 in
>> mergeinfo will not create a new repository with identical contents?
> dump/load will preserve the mergeinfo property value exactly in this case.
>
> svnsync will change the mergeinfo property value in this case.
>
> This is not the only case where 'load' or 'sync' changes repo contents even when the revnums and paths are staying the same:
>
> * 'svnadmin load' always rewrites mergeinfo, which can change its form
> even if it doesn't need to change it semantically. (Except, since
> r1643074, if it's unparsable, it loads it unchanged instead of bombing
> out.)
>
> * svnsync always 'normalizes' properties (encoding to UTF-8, EOL style to LF).
>
> That's what we have. For 'svnadmin load' I think that's not ideal: there should be a way to force it to load exactly what's in the dump file, for data that *could* have been dumped from this version of repository and server. For 'svnsync' I think it's reasonable that it should try to normalize metadata that may be considered invalid by the target repository, although other approaches may be possible.

Ack ... sounds reasonable, given current behaviour in general.

-- Brane
Received on 2014-12-17 19:56:24 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.