GNOME.org
 

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

On Wed, 2012-08-08 at 07:35 -0400, Adam Tauno Williams wrote:

On Wed, 2012-08-08 at 10:05 +0100, Pete Biggs wrote: 

On Tue, 2012-08-07 at 13:24 -0600, Brian A Anderson wrote:

<Begin editorial mode>
The key things that I learned here are;
1.  the two different versions of Evolution had two different mailbox
styles. 
2.  The two versions of Evolution were not compatible.
3.  the evolution of Evolution had abandoned those with older systems.
    Cynical but apparently true.

I don't think that's entirely true or fair. 
Did you give Evolution a chance to upgrade your data structure? 


Yes, the user posted about their success/failure using
backup-and-restore to this list.  backup-and-restore is pretty well
known to not work across multiple major releases.



Again my situation was a bit different as I said in my first paragraph.
I was really doing a merge more than a restoration.
So some of the suggestions were never going to "really" work completely.


i.e. did you start Evolution
with the old files in their original place rather than trying to do it
through the backup files? 


Yes; or at least I believe the poster said that.


Backwards compatibility is very important.


To a point; but the user is jumping across many major releases.  It is
unreasonable to expect it to work well, IMNSHO.  This is like jumping
from Microsoft Access 97 to Microsoft Access 2010;  it 'works', but a
fair amount of remediation is required.   Oh, gawd.. now I'm having
flash-backs...



First of all the version of a piece of software is merely a way of
categorizing a set of procedures it should have no further impact.
Consider this;  Take for example how we consider travelling.
We are all canonical travellers,  we are passengers on planes, we have
luggage.  But none of us need to know what kind of plane, how it works
etc.  The way in which Ohare, JFK,  Logan,  SFO, LAX etc all work are
slightly different. We don't need to care about those issues.
Now look at evolutions data store.
Each canonical message under 2.24.5 and 3.4.3 are stored differently.
Yet they arrived into their versions of evolution using the same
mechanisms.   
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.
So How many users really want to be slaves to version creeping and
version hopping?



Evolution 2.24 is *old* [circa 2008].  Especially in Evolution time
where things seems to sit stagnant at the 2.2x level for a long time and
then pulsed forward through 2.3x and now on to the [vastly improved] 3.2
and 3.4 era.

But the user did publish notes, so kudos.  Might be useful to someone
else later on.


Evolution is probably one of the best applications I know for upgrading
internal storage formats - it is quick, unfussy and accurate.


Yep.


Some versions may not offer a real reason to migrate.
I for one don't want to become a slave to updates like Windows users
are a slave to updates.

But you *must* install updates for any operating system - they fix bugs
and, most importantly, they fix security holes.  It just simply should
not be optional to install updates.


The user certainly doesn't need to rush to update; too many LINUX users
are addicted to the next-greatest-patch which is an attitude that
seriously impedes real world productivity [hey, let me update first
thing Monday morning and break my desktop!].  'Immediate update' also
provides no pragmatic upside [let's be honest - *most* security fixes
are pretty obscure and only effect boxes using particular
applications/services in a particular configuration].


Name me two security fixes to Linux that fixed publically seen and
experienced problems.  Not just those that some security geek says are
important and are possible.  But happened.
By the way I used to work in network security.



I apply updates once a month; and I typically upgrade my distro a full
month after a release [plus a month worth of updates].  This has
provided me with a very smooth ride.  I try to recommend this policy,
but immediately after I say this most users are subscribing to a factory
repository and doing a "zypper up"... sigh. :)


I am glad that you have had a good luck with a monthly update.
I have in several years attempted only two updates.
AND BOTH FAILED TO COMPLETE!
The last one left me with a dead system.


In that case, with all due respect, why are you using Fedora! If you want
stability, then use a RHEL clone such as CentOS or ScientificLinux -
they will guarantee support for about 5 years after EoL of a particular
version - but you still have to install updates.


Agree. If long-term is what the user is looking for then Fedora is a
mismatched choice.  Fedora *is* the distro of latest-and-greatest [which
is not a criticism, but maybe that is not where the user wants to be].


Not really relavent. As the concept of having a stable system to use in
an office setting with seldom if any updates is not a risk even in your
latest/greatest observation.  The greatest risk once a stable system has
been found and evolved to, is the introduction of updates.  

I started using Linux vs Windows as an attempt to explore alternative
environments for an occasional developer (read as semi-retired).  I
found that once stable it was good.  There were/are some shortcomings
but it has worked for me.  My Linux laptop is up for more than 30 days
at a time without restarting.    My longest stint with any Windows was
about 3 days and then that laptop almost rebooted itself.  

I do have a real problem with doing updates for the sake of updates.
I don't go and buy the latest version of any technology because it came
out.  Like the Tommy Lee in "Men in Black",  "now I guess I have to buy
the Beatles White Album again".  Why can't a stable system be put
together occasionally that can be moved to that has the ability to
migrate data forms.  Remember the canonical form.  If it were used
migration would never be a problem. 

_______________________________________________
evolution-list mailing list
evolution-list gnome org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]