On Fri, 20 Mar 2009, Mark Stead wrote:
> 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.
No, say i use "-c 20" and HEAD is r35, then i get the following dumps:
repos.0-19.svndmp
repos.20-35.svndmp
Then I change it to "-c 10", continue committing until r45 and get the
following dumps:
repos.0-9.svndmp
repos.10-19.svndmp
repos.20-29.svndmp
repos.30-39.svndmp
repos.40-45.svndmp
svn-restore-dumps.py will then load 0-19 and 20-35 instead of
0-19, 20-29, 30-39 and 40-45.
>> - 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).
Same situation here, the messy user (me) will continue to work and forget
about the old full dump...
>> - 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).
Right.
> 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.
Thanks. But it's not black magic, just a bit... ehmm... 'compressed' ;)
> 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?
That's also a good way. If something goes wrong the user will be informed
after a few milliseconds. This is still much better than waiting a few
hours and then getting an error.
> 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=1366721
Received on 2009-03-20 20:17:06 CET