Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3

[Brian A Anderson <BrianAAnderson q com>]

On Thu, 2012-08-09 at 12:06 +0100, Pete Biggs wrote:
> > Why should the backup not maintain a canonical form of all the aspects
> > of a mail system vs backing up on the way in which the data is stored.
> > A canonical form would have forced all versions to be able to backup and
> > restore with full backwards and forwards compatibility.
> > The canonical form could evolve with versioning of data forms as they
> > get more complex and programs evolve.
>
> Sorry, I didn't really address the underlying aspect of what you are
> saying here.
>
> In the dim and distant past email was held in standardised data stores -
> i.e. mbox files.  It was an almost universal standard and no matter what
> program you used, it could be read and modified and other programs would
> still be able to work with it.  And Evolution used that standard.  To
> all intents and purposes, that was the canonical form.  Then some kind
> person invented MIME and the size of email messages expanded
> exponentially and all of a sudden the forever canonical form was not
> good enough - the files became too big, too unwieldy, too slow and
> things had to change.
>
> Similarly with configuration data - in the early days of Unix and a
> single INBOX on your local system, there was no configuration necessary
> - then POP, then IMAP, then Exchange all came along and something,
> somewhere had to remember what the program was supposed to do.  There
> was no standard for such info so every program did its own thing.  Evo
> did have a canonical form of the data, it was in flat files in the
> Evolution private folders, but that eventually became too slow and too
> fragile, so they changed to using gconf - which is now being deprecated
> in favour of dconf.
>
> What I'm trying to say is that 20:20 hindsight is a wonderful thing -
> but it is incredibly difficult to design a data storage format that is
> totally impervious to future changes and is efficient enough for
> everyday usage.  I'm also fairly certain that if there was a standard
> for holding or exchanging account information and data between different
> programs, then Evo would have embraced it.

What you said about mbox is not about canonical form. It is a standard
way of storing mail info.  The proper/canonical way of doing a backup is
to read each canonical item from whatever store mechanism you use and to
stores it canonically for restoration.   The restoration process is the
reverse it takes canonical items from a canonically organized store and
places that data  into whatever storage mechanism is used in this
application.    Thus each version, more importantly each version that
has a different mbox, maildir etc method of storing info would have a
different backup and restoration set of routines.

Evolution does NOT use a canonical backup.  It uses a trivial file
backup using tar.  At least for the 2.24.5 version that I was worried
about getting files from.

The Maildir mechanism used currently is not canonical either it is yet
another "standard" way of storing the mail data.


> Finally, I would just point out that the best way of maintaining email
> for use on multiple systems and that is fairly impervious to changes in
> version is to keep your mail on a server and access it using IMAP - that
> way you don't have to worry about moving data and if the upgrade
> procedure doesn't work, all you will ever have to do is to re-enter the
> account configuration.

Hindsight is perfect isn't it.
I was never really interested in a multiple system environment.  It was
forced upon me as I was forced to retire a sick and dying machine and
replace it with another machine.  I do not live in a network hub.  MY
network here is not as reliable as I would like.  Nor is my ISPs mail
server. Therefore I must be able to see messages that I have received on
my machine even if I don't have networking available.

While some models for what a user of a computer or a computer program
are may make all users homogenous,  I assure you that we are not
identical in any way shape nor form.  We all have our own needs and
methods of work.   You may like some and dislike others.  But we all use
tools differently.   In a true office environment at a workplace the IT
department can force procedure.  I am not in that environ, I must choose
by own based upon my experience and lack of interest in  version
chasing.


What made my situation in this scenario weird by how some would view the
use of different versions of evolution is that I had data that I finally
got via backup off of the dying machine.   But before the dying machine
actually dies I got the new machine up and running and started using it
versus being cut off and not having any mail service at all. Or
conversely living on a dying machine while I figrured out how to do a
multiple version migration. Thus I wandered helplessly into a merge of
data from my old system into data that is/was currently arriving.

The process I used was to attempt to perform a backup of the old system
using the evolution backup command.  That file was named in the attempt
from the new version of evolution 3.4.3s restoration command.  This
restoration failed.  This is the proof that the backup and restoration
between the two version I used was incompatible (see next para). This
was the process that made the most sense and was suggested/recommended
by many on this list.

Some have objected to my comment that the evolution of Evolution has
left users of older version behind as being incorrect.  It is a FACT
that the backup/restoration between these versions is not compatible !
Therefore the statement is TRUE!  What is debateable is whether a user
should be version chasing or not.  The key thing that I need as a user
not a builder/developer is the identification of key releases of the
product that are stable and have real value to me as a user. 


By the way this post is not meant strictly to Pete.
It is more a generic response to several messages.
> P.
>
>
>
> _______________________________________________
> evolution-list mailing list
> evolution-list gnome org
> To change your list options or unsubscribe, visit ...
> https://mail.gnome.org/mailman/listinfo/evolution-list