On 8/3/2016 3:40 PM, Nico Kadel-Garcia wrote:
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.
[...]
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.
And here is where IMHO the flaw in your argument lies: The assumption
that the data you are discarding is unwanted.
Especially by suggesting new people to discard these information you are
neglecting the fact that especially this user group is likely to have
less experience with versioning systems than you or others would have
and are possibly not in a position to correctly evaluate/realize what
the impact of the discard will be for their particular case/needs.
You are focusing again on "only" losing the history data (which, I
believe I've stated before, is IMHO one (if not THE ONE) most important
data in a version system), while you actually will drop a lot more.
Especially in the scenario you are now suggesting to perform an
export/import process over a dump/load process when >upgrading< from one
to another major subversion version (rather than doing a migration from
one to another CVS).
In this case you will loose all the additional data SVN uses/collected,
not only the history. Mostly I'm referring here to the SVN properties.
Depending on the integration/use of this data, you'd break the
integration in the infrastructure for example.
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.
Sorry but I can't share your opinion about svnadmin dump/load being
potentially dangerous --- at least not in that this is more dangerous
than a simple export/import with regards to data consistency.
To perform a dump load and then verify the integrity you would do:
dump -> load -> dump -> compare old vs. new dump
If there are differences between the dumps (which really normally
shouldn't be the case) you determine where the difference are coming
from. The mailing list will provide you with the necessary support to
evaluate the impact of the difference you see.
In your export/import approach you would do:
export -> import -> export -> compare old vs. new export
And like with the dump/load/dump approach above, if you see a difference
between the two exports you would then investigate their cause.
Without the final verification step (in both approaches) you certainly
can not be more confident that the process worked flawlessly and you
ended up with what you want.
So once more: I'm sorry, but I really can't even to the slightest share
your believe in that export/import is anywhere
better/easier/more-suitable (in the general case) than a dump/load-cycle.
As said before: there might be very specific cases where this might be
preferable over complete data migration step. But I can't imagine a
single case where this would be preferable over a dump/load/dump cycle.
--
Regards,
Stefan Hett, Developer/Administrator
EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473
