[Evolution] Use standalone migration tools (war: Data migration Evolution 2.24.5 to 3.4.3)



Am Dienstag, den 07.08.2012, 09:05 -0600 schrieb Zan Lynx:
On Mon, 2012-08-06 at 16:33 -0400, Matthew Barnes wrote:
On Mon, 2012-08-06 at 13:31 -0600, Brian A Anderson wrote:
If I follow what you said below,  Does this mean that I have to convert
2.24.5 data to 2.32 data and then to 3.4 or is it just one conversion?
Is there a utility that someone has that might do this job?

You don't HAVE to, but I think what Andre meant is the bigger the jump
the bigger the risk.

Migration routines are written to convert data from the previous major
release to the upcoming major release at the time of writing.  So if I
wrote a new routine today it would convert something from the way it's
represented in 3.4 to the way it will be represented in 3.6, and that's
about as much testing as it receives prior to release.

The theory goes, as the routines execute chronological order, the data
undergoes one or possibly multiple conversions but should end up in the
currently supported representation.  But as time passes, old migration
routines may bit rot and silently break.

Case in point: I believe the mbox-to-Maildir conversion itself still
works in 3.4 but the detection for when the conversion needs to run is
currently broken because it relies on some subtle aspect of the startup
sequence that has changed since 3.0.

In my experience, one of the better ways to do data conversion is to
write an independent program to do it. Name it something like
evolution-convert-3.2-3.4. After enough time, you would have a
conversion program for each version and they could be run in order. They
could also run without requiring a full working Gnome/Evolution
environment so they could be used to convert offline data. On a backup
server for example.

I second that. Nobody is perfect and therefore somebody will be bitten
by a bad migration and currently has no way to manually redo the
migration.

Hopefully the developers will think about that and hopefully follow that
approach in the future.


Thanks,

Paul

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]