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
