Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
Am Sonntag, den 19.08.2012, 17:57 -0400 schrieb Adam Tauno Williams: […] Evolution supports GroupDAV / CardDAV [in Evo it is called WebDAV] for contacts and CalDAV for tasks, events, and memos. And Evolution is just about the only client to actually support *attachments* via CalDAV for tasks and appointments - which is simply awesome. That's pretty interesting. I didn't take time for that up to now :-( Can you describe a concrete scenario of usage of all that ? What Server would you suggest ? -- Best, Thomas ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
Am Donnerstag, den 09.08.2012, 08:47 -0430 schrieb Patrick O'Callaghan: On Thu, 2012-08-09 at 12:06 +0100, Pete Biggs wrote: 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. +1. In fact since Evo has supported IMAP since the beginning, a migration strategy for widely separated versions is to move the old mail onto an IMAP server, switch Evo versions, then just access it with the new one (or download it again if you really must). Pity this isn't so easy for contacts, tasks, filters etc. Blame me, if I'm a little off topic, but: Didn't UbuntuOne offer a service to synchronize - at least - contacts ? I did not yet have a look at how they do it. If they do it with simple file copy, it may be another way that doesn't solve the problem ... Is there any experience with it ? ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
On Sun, 2012-08-19 at 17:10 +0200, Thomas Prost wrote: Am Donnerstag, den 09.08.2012, 08:47 -0430 schrieb Patrick O'Callaghan: On Thu, 2012-08-09 at 12:06 +0100, Pete Biggs wrote: 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. +1. In fact since Evo has supported IMAP since the beginning, a migration strategy for widely separated versions is to move the old mail onto an IMAP server, switch Evo versions, then just access it with the new one (or download it again if you really must). Pity this isn't so easy for contacts, tasks, filters etc. Blame me, if I'm a little off topic, but: Didn't UbuntuOne offer a service to synchronize - at least - contacts ? I did not yet have a look at how they do it. If they do it with simple file copy, it may be another way that doesn't solve the problem ... Is there any experience with it ? No, the UbuntuOne service never made any sense to me. Evolution supports GroupDAV / CardDAV [in Evo it is called WebDAV] for contacts and CalDAV for tasks, events, and memos. And Evolution is just about the only client to actually support *attachments* via CalDAV for tasks and appointments - which is simply awesome. signature.asc Description: This is a digitally signed message part ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
On Thu, 2012-08-09 at 12:08 -0600, Brian A Anderson wrote: In the long run an IMAP server is not really a good solution for I have a less than perfect/good ISP. I still need to access mail that arrived both distant past and recent past. Neither happen if either ISP net or ISP's imap server go down. Obviously, I am not using my Linux system in an office building with a real IT team. Neither am I, nor I suspect are many people on this list. Furthermore, if your ISP is unreliable, it's also unreliable for POP. There is nothing you do with POP that you can't do with IMAP, including storing all your mail locally. poc ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
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. And you were doing a merge because you started using Evolution before letting Evolution see your original data - that's really what I was getting at. Yes, the upgrade procedure from very old versions of the backup file is less than optimal, but I don't think that is sufficient grounds to say that Evo abandoned those with older systems, especially when you didn't really give it a chance to update in-situ files. 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. Yes, the backup/restore process is fairly naive - it is basically dump the config data from gconf (or dconf) and then tar it up with the data files - the restore process is the reverse, untar the data and dumped configuration, then merge the config into gconf. The problem with using such an old backup file is that the format of all the components (configuration and data store) has changed, as well as the location of those files. It was never meant to be used when upgrading systems, it was meant to be used to backup and restore data to the same version. The canonical form could evolve with versioning of data forms as they get more complex and programs evolve. Yes, that would be a good ideal - I'm sure the developers would welcome any help you can give them in re-writing the backup and upgrade code. The issue really is how much effort should be put in to dealing with something that is relatively rarely used - the developers team is small and they are hard pressed. If you think this is an area where Evolution needs to be improved though, then file a bug on it, and if it is given sufficient support, then no doubt it will be looked in to. So How many users really want to be slaves to version creeping and version hopping? Users don't - that's why I put them on systems that don't have short lifetimes. 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. Metasploit (a framework for ethical intrusion and penetration testing) has over 650 usable, live remote exploits for Linux. There are then a whole load of privilege escalation exploits to gain root. Not all the exploits work, mainly because systems have been updated and patched so they don't work. But they do work on systems that aren't patched. Before I took control of all the Linux boxes where I work, I was having to deal with intrusions about once a week - virtually all of them on unpatched systems; now I enforce updates and have locked the machines down, I get virtually no intrusions. These are real world, real intrusions, real data loss, that happened. 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! Updates or upgrades? I have about 200 Linux systems, they automatically update from repositories (strictly controlled repositories!) and I've never had an update that left a system in an unusable state. Upgrades are different matter. You can't do major version upgrades on RHEL/CentOS systems, it is always a wipe and re-install. 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
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
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. 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. 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
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
On Thu, 2012-08-09 at 12:06 +0100, Pete Biggs wrote: 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. +1. In fact since Evo has supported IMAP since the beginning, a migration strategy for widely separated versions is to move the old mail onto an IMAP server, switch Evo versions, then just access it with the new one (or download it again if you really must). Pity this isn't so easy for contacts, tasks, filters etc. poc ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
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
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
On Thu, 2012-08-09 at 08:47 -0430, Patrick O'Callaghan wrote: On Thu, 2012-08-09 at 12:06 +0100, Pete Biggs wrote: 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. +1. In fact since Evo has supported IMAP since the beginning, a migration strategy for widely separated versions is to move the old mail onto an IMAP server, switch Evo versions, then just access it with the new one (or download it again if you really must). Pity this isn't so easy for contacts, tasks, filters etc. poc Again this is not a practical way for me to have solved my problem. I was forced into the situation by having a dying machine. I believed I had minimal time once my system started to fail until it was gone. In the long run an IMAP server is not really a good solution for I have a less than perfect/good ISP. I still need to access mail that arrived both distant past and recent past. Neither happen if either ISP net or ISP's imap server go down. Obviously, I am not using my Linux system in an office building with a real IT team. Perhaps if I had 25 years ago had started with a system like IMAP, I would not have gotten used to using a mail system that loads mail messages into my local space. Isn't hind sight perfect. Another feature that IMAP presents could be support of multiple systems. And again I don't have a real multiple systems usage. I have 2 laptops one old, one new. Old one is dying. IE I am headed to having one laptop. Also I am using Evolution for mail use only and don't really care about calender, contacts etc. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
[cut] I hope this helps others so afflicted. Thank you for sharing Brian. Sadly not many people think about others these days. -- Patryk LeadMan Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
Hi :) I agree it would be nice if there were more people like Brian and the various people that help on this or other such lists and forums and of course the devs both here and in other similar projects. There might not be as many such people as we would like but there are a lot and they are quite prolific and very much appreciated. Many thanks all!! Keep up the good work! (sorry about top-posting htmling btw) Regards from Tom :) --- On Wed, 8/8/12, Patryk Benderz patryk.bend...@esp.pl wrote: snip / I hope this helps others so afflicted. Thank you for sharing Brian. Sadly not many people think about others these days. -- Patryk LeadMan Benderz Linux Registered User #377521 () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
On Tue, 2012-08-07 at 13:24 -0600, Brian A Anderson wrote: Attached is the file notes containing my notes about the migration of Evolution data from 2.24.5 to 3.4.3. The basics of this file is the procedure to migrate data (not a complete configuration) from 2.24.5 to 3.4.3. The data can be merged into already existing data running under 3.4.3. Thanks for your notes on how you did it. A couple of observations, and in no way is this a criticism of your method. First, I'm always very wary of playing around with Evolution's private files (i.e. the ones under .local) - if you know what you are doing, then it will probably be fine, and Evolution will try and cope with inconsistencies introduced by altering files manually. However, that may not always be the case, and naive tinkering with those files may cause data loss. At the very least, when you say shut evolution down, you should make sure it is fully terminated using the command evolution --force-shutdown to make sure there is nothing hanging around that might introduce inconsistencies. Second, as I've said a few times on this list before [1], the easiest way of importing files from the old mbox format (if the automatic translation doesn't work) is to make a copy of the old Evolution data tree somewhere, find which directory all the mbox files are held in, then create an account within Evolution of type Standard Unix mbox spool directory and point the path at the directory containing the mbox files. The new account in Evolution will then contain all your old mail. You can then copy all the mail you want from that account into the normal folders in Evolution. This will ensure that all Evolution's files are kept internally consistent. Once you've copied all the mail over, you can remove the account in Evolution. But the beauty of Unix is that in general there is more than one way to achieve a result - all methods are equally valid, just use the one that works best for you. 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? i.e. did you start Evolution with the old files in their original place rather than trying to do it through the backup files? Backwards compatibility is very important. The useful migration of data is not as simple as constantly updating your mailsystem as each version comes out. Evolution is probably one of the best applications I know for upgrading internal storage formats - it is quick, unfussy and accurate. Most of the time you don't even know it's happened. It's a damn sight better than apply this sql patch, run this program, apply next sql patch, delete the following directories etc. etc. that I often come across. 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. Rather I look at my Linux environment the same way I looked at HP-UX as a stable working environment that changed when we had to. Not just as HP came out with new versions. When our old machines became HP Obsolete then we were forced to move. In that case, with all due respect, why are you using Fedora! Fedora versions are obsoleted after about a year - which means that all updates, including security ones, will cease. And you really, really don't want to run a Linux system without security updates. 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. P. [1] e.g. https://mail.gnome.org/archives/evolution-list/2012-June/msg00042.html ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
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. 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... 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]. 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. :) 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]. signature.asc Description: This is a digitally signed message part ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
On Wed, 2012-08-08 at 09:51 +0200, Patryk Benderz wrote: [cut] I hope this helps others so afflicted. Thank you for sharing Brian. Sadly not many people think about others these days. In my more than 25 years of UNIX, Linux, QNX etc experience , I have encountered a number of folks that hoard information/procedures and how tos like they were magic spells that only a true magician could possess and use. Since I learned much from that type of pseudo guru on my way to gurudom, I decided a while back to pass what I learned onto others so they could benefit. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
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
[Evolution] Notes on Data migration Evolution 2.24.5 to 3.4.3
Attached is the file notes containing my notes about the migration of Evolution data from 2.24.5 to 3.4.3. The basics of this file is the procedure to migrate data (not a complete configuration) from 2.24.5 to 3.4.3. The data can be merged into already existing data running under 3.4.3. The scenario I was under was; 1. I had an older system running Fedora 10 Evolution 2.24.5 that had an apparent hardware failure. 2. A new laptop running Fedora 15 with Evolution 3.4.3 3. I already had the new systems email up and runnning. 4. I was not using calender or other features of the Evolution on the old system. I hope this helps others so afflicted. I would like to thank those that contributed information to my search for a solution. This file is a set of notes about how I solved a problem migrating from an older machine running Fedora 10 with Evolution 2.24.5 to Fedora 15 Evolution 3.4.3. My older machine was dying a hardware death and I considered it unable to be updated or changed in any way. My new machine had arrived and I got connected to my ISP server using Evolution 3.4.3. So it went from a simple migration into a merge. I had mail already present that 3.4.3 new about and mail that was valued from the old machine. While the old machine was working I got Evolution 2.24.5 to perform a backup into a local file evolution-backup.tar.gz That file was moved to the new machine using one of those USB flash drives. What follows is a procedure/dialog about how to get various message folders from the backup of the old 2.24.5 data into the area of the new 3.4.3 system. First some symbols I used OLDEVOL=$HOME/mytest/old/.evolution/mail/local NEWEVOL=$HOME/.local/share/evolution/mail/local TMPEVOL=$HOME/mytest/new Place that backup file in your home dir from my flash drive $HOME/evolution-backup.tar.gz So as to reduce vulnerability I did a backup of 3.4.3 and set it aside. Then I worked in a temporary directory called mytest This area would hold both the backup from the old system and converted folders prior to populating the new evolution tree. mkdir $HOME/mytest cd $HOME/mytest mkdir new old I placed the old mailbox system into old cd $HOME/mytest/old tar xvf $HOME/evolution-backup.tar.gz A quick view of the resulting directory was disappointing at first but I realized that the data was really visible at $OLDEVOL Each working folder for our example OURFolder under the old system was visible as four files OURFolder OURFolder.cmeta OURFolder.ibex.index OURFolder.ibex.index.data The actual email messages were found in OURFolder. As this procedure deals with selective restoration of a folder from the old to the new we will use the name OURFolder. This is the name it would have appeared as under Evolution 2.24.5. And ultimately under 3.4.3. We are going to build a temporary copy of the mail messages in our mytest directory tree. $HOME/mytest/new I used a perl script I found on the internet. The file was mb2md-3.20.pl It came from batleth.sapientia-sat.org/projects/mb2md It needs to have a TimeDate Perl library loaded. I installed a package using RPM. Sorry, but I cannot remember where I found it. I found it using google looking for Perl TimeDate The original mail mbx file is located by $OLDEVOL/OURFolder The new directory in our working Evolution 3.4.3 will be located by $NEWEVOL/.OURFolder/cur Note the . before OURFolder The conversion will go from a single file $OLDEVOL/OURFolder to a directory $NEWEVOL/.OURFOLDER/cur that contains files each with a separate email message. We will place the files in a temporary dir $HOME/mytest/new my nomenclature for this is TMPEVOL perl mb2md-3.20.pl -s $OLDEVOL/OURFolder -d $TMPEVOL/OURFolder The script will kick out some complaints but will do all the messages. No here is a find point to examine. The script uses a procedure to convert. I found it worked for my mail from my ISP. There is a option in the script to do the conversion a bit differently. So it may be necessary to read some of the messages and see if they make sense. Not really likely unless one speaks email header gibberish. take a look at $TMPEVOL/OURFolder/cur There will be many files. One per email message encountered by the conversion perl program. If it looks good. Now remember it is the raw message. evolution will change its appearance. NOW THE MOST IMPORTANT PART enter evolution create a new folder OURFolder Shut evolution down. copy the files from our temp directory to the 3.4.3 directory cp $TMPEVOL/OURFolder/cur/* $NEWEVOL/.OURFolder/cur note the . infront of the OURFolder in the destination directory This means you must get used to using the -a option in ls to see these folder/directories as you work with them. NEXT IMPORTANT PART enter evolution select OURFolder (the name we used) sit and wait select inbox select OURFolder the converted mail messages should be there
