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

Re: [RFC] Incremental dumps and mergeinfo (Was: Vetoing latest issue #3020 fix in 1.6.10)

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 15 Apr 2010 09:28:01 -0400

Julian Foad wrote:
> On Wed, 2010-04-14, C. Michael Pilato wrote:
>> Assuming similar behavior for mergeinfo handling, we have, at a minimum:
>> 1. 'svnadmin dump' warns when it is in incremental mode and must generate
>> mergeinfo from a merge source that predates the beginning of the dump
>> window, but it's only a warning and the dump continues.
> +1 on that, both for consistency with copy-source info and because it's
> a good policy anyway.
> A detail: I haven't tried it, but would want it to print this warning
> (and the copy-source one) at the end of the dump, and not just in the
> middle of the long list of "Dumping rX" messages.

Currently the warnings are all "inline". But I agree that it would be
beneficial to also just track boolean flags (had_suspect_copies,
had_suspect_mergeinfo) throughout the dump and repeat warnings at the end:

if had_suspect_copies:
  print "WARNING: The range of revisions dumped contained references "
        "to copy sources outside that range."
if had_suspect_mergeinfo:
  print "WARNING: The range of revisions dumped contained references "
        "to mergeinfo outside that range."

>> 2. 'svnadmin load' does nothing smart, trusting that the dump it's being
>> fed is a sensible one.
> Better: 'svnadmin load' tries to validate the mergeinfo, and issues a
> warning if it refers to a non-existent source. The admin then gets to
> figure out whether it was bad in the first place or because of his/her
> partial-dump/partial-load scenario.
> However, it depends how efficient the checking is. If that would make
> the 'load' really slow, I can see that not being wanted.


C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2010-04-15 15:28:36 CEST

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.