[Kde-pim] KDEPIM Needs More TIme
vkrause at kde.org
Tue May 18 09:09:48 CEST 2010
On Monday 17 May 2010 13:20:07 Sebastian Kügler wrote:
> On Sunday 16 May 2010 13:25:28 Ingo Klöcker wrote:
> > On Sunday 16 May 2010, Lindsay Mathieson wrote:
> > > On Sun, 16 May 2010 05:19:49 am Ingo Klöcker wrote:
> > > > All you will lose is some meta data (e.g. the state of the
> > > > messages). Another advantage of limiting the migration to the meta
> > > > data (e.g. the information in KMail's index files) is that there
> > > > is less potential for migration errors.
> > >
> > > That's good to know, sounds reasonable.
> > >
> > > How about the config data? Account setup etc.
> > Config data is the real problem. It is likely to get lost on the
> > migration. As this has always been the case with almost all upgrades of
> > KDE PIM (e.g. when the configuration of the sending accounts was moved
> > from kmailrc to another file or when the configuration of the identities
> > was moved from kmailrc to another file) I don't see why we should handle
> > this differently for this upgrade. A possible solution would be to leave
> > kmailrc untouched and use kmail2rc for KMail 2, but I'm not sure it's
> > worth doing so.
> What is so hard about migrating config data? At least the account setup
> doesn't look too complicated to the naive me.
Account migration works fine, since quite some time already. And thanks to
Kevin's recent work data migration looks very good as well, including the
meta-data stored in KMail's old binary index files.
The only problem is, as has been pointed out already, there is no clean way
back. Once KMail2 wrote new mails into your old local folder tree, KMail1
will no longer accept the old index files belonging to that and thus you'll
lose your meta-data in that process. It can of course still read the actual
data and IIRC the account data still stays in the config file.
Of course there will be some glitches, it's simply not possible to test all
the configuration variants you find out there and not everything can easily
be mapped exactly to the new stuff. But it's not as bad as sometimes painted
here, the basic stuff (data, most meta data, account setups, etc.) is already
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20100518/7817a649/attachment.sig
More information about the release-team