On Wed, Aug 3, 2016 at 9:02 AM, Ryan Schmidt <subversion-2...@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.
