On Wed, Aug 3, 2016 at 9:02 AM, Ryan Schmidt
<subversion-2016_at_ryandesign.com> wrote:
>
> On Aug 3, 2016, at 7:54 AM, Nico Kadel-Garcia wrote:
>
>> On Wed, Aug 3, 2016 at 2:16 AM, Ryan Schmidt wrote:
>>>
>>> On Aug 2, 2016, at 9:54 PM, Nico Kadel-Garcia wrote:
>>>
>>>> On Tue, Aug 2, 2016 at 7:15 AM, Ivan Zhakov wrote:
>>>>
>>>> [dump/load cycles omitted]
>>>>
>>>> Please note. This sort of pernicious bug is why I suggest takeing a
>>>> clean export/import when moving to significantly newer versions, or
>>>> significantly new project versions, for Subversion repositories. Don't
>>>> hurt yourself trying to preserve burdensome, possibly flawed history
>>>> you *do not need*.
>>>
>>> PLEASE STOP.
>>
>> Sorry, Ryan, but it needed saying.
>
> No. I understand you have personal experiences with transferring history that have led you to prefer not to do so, but most of the Subversion developers and other members of this list do not share your views on this matter and I ask you again to refrain from working this opinion into every thread on this mailing list. The one-time existence of a bug in a feature does not mean that one should forever avoid using such a feature even after the bug has been fixed. And just because something like transferring history can be difficult to get right does not mean that the correct answer for everyone is not to try to do so.
I don't insist on it: it's not always the correct answer. But it's not
the only time dump/load has suffered from bugs, and I'm sure it won't
be the last. In many cases it can save a great deal of work and should
be considered as one of the first options for complex migrations,
instead of the very last, for reasons I've mentioned before.
For new people: I've mentioned doing an svn export/import to a new
repository, instead of an svnadmin dump/load, as a useful migraiton
approach on various occasions for years now. It does discard history,
but it's the cleanest way to dump unwanted content and make a clean
start with a new layout. It was a potentially useful approach that
hadn't been mentioned for this thread, and I felt that Stefan (and
others faced with expensive, potentially dangerous svnadmin dump/load
cycles) should keep it in mind for their next migration.
Received on 2016-08-03 15:41:08 CEST