2009/3/20 Martin Furter <mf_at_rola.ch>
>
> Hi Mark
>
> You're right, your version works perfectly for the normal cases.
>
> But there are various cases which create dump files which cause it to fail:
>
> - Using svn-backup-dumps.py when "-c 20" is changed to "-c 10".
Only if particularly devious. For example, dump 0-35 with "-c 20", then
dump to revision 45 with "-c 10". The (bogus) restoration path would be
0-19, 20-35 instead of 20-29, 30-39 etc.
> - A full dump, maybe made to upgrade subversion.
I would have thought this scenario would still work. If restoring into a
new repository, then it should use the full dump (since highest end
revision). Otherwise if restoring to an existing repository then the full
dump could not be considered (since start revision < youngest).
> - Some custom dump file surgery.
> ...
>
> Ofcourse it's easy to fix, just rename the offending dump files or move
> them away. But it would be nice if it just did the right thing.
Doing the right thing is always a desirable trait. It is more important to
not screw things up for the user (ie protect them from themselves).
Anyway, I've had a look at your code. Please don't take offense, but it
exceeded my threshold for readability. What you've written is very complex,
and it is a credit to you that you've figured it out.
In the interest of keeping things simple (yet preventing problems), what
about an alternate approach:
Traverse the dump revision chain to determine which revision we will
actually end at. If this revision is less that the highest dump revision,
then tell the user we've got a problem - and get them to sort it out. If
the initial run through looks good, then proceed with loading the dumps.
Your thoughts?
On Tue, 17 Mar 2009, Mark Stead wrote:
>
> Hi Martin,
>>
>> Thanks for your feedback. I haven't looked at your attachment yet - it
>> sounds complex though.
>>
>> Can I clarify how you would get the dump 20-44 created.
>>
>> I assume you are using svn-backup-dumps.py with "-c 20". You will get
>> multiple files, but they should only contain at most 20 revisions and
>> start
>> at a multiple of 20.
>>
>> For example, this is what I'm expecting to see when dumping at head rev is
>> 35
>>
>> - Dump 0-19
>> - Dump 20-35
>>
>> Then continuing when head rev is 44
>>
>> - Dump 20-39
>> - Dump 40-44
>>
>>
>> When restoring from these dumps it will use 20-39 in preference to 20-35
>> since it chooses the one with the highest end revision. This will work
>> when
>> restoring into a new repository.
>>
>> But it does give problems if you are restoring into a repository already
>> at
>> revision 35 (ie one restored from a full backup). In this case there is
>> no
>> way to restore revision 35 onwards without manually modifying the dump
>> files. This is why I made the "relative incremental" changes to
>> svn-backup-dumps.py.
>>
>>
>> Perhaps there may need to be operational restrictions - such as:
>>
>> - It is preferred to use "relative incremental" mode (-i) of
>> svn-backup-dumps.
>> - Use -c mode, but only if you don't vary the count value between dumps.
>> - Using -c mode may limit your ability to restore into an existing
>> repository. You should be able to restore into a new repository (if you
>> have dumps from revision 0). Or if desperate you can edit a dump file to
>> include only the revision range required.
>> - Of course "full dump" and "single revision" dump modes should be fully
>> supported.
>>
>>
>>
>>
>> 2009/3/17 Martin Furter <mf_at_rola.ch>
>>
>> Almost perfect... ;)
>>>
>>> I found another problem. If you have the following dump files:
>>>
>>> rps.000000-000019.svndmp
>>> rps.000020-000039.svndmp
>>> rps.000020-000044.svndmp
>>> rps.000040-000059.svndmp
>>>
>>> It loads 0-19, 20-44, then fails because it can't find a dump file
>>> starting
>>> with revision 45.
>>>
>>> The attached version contains an enhanced scan_all_dump_files function.
>>> It
>>> creates a graph of all dump files from HEAD+1 up to the highest revision,
>>> then throws away all nodes which have only one or no connection. After
>>> that
>>> it chooses a path from HEAD+1 to HIGHEST and ignores redundant sub-paths.
>>>
>>> I hope you like it, though it's much more complicated.
>>>
>>> Martin
>>>
>>
>> ------------------------------------------------------
>>
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1336604
>>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1361959
Received on 2009-03-20 12:13:28 CET