Re: [Evolution-hackers] [opensuse-gnome] Evolution 2.22 for Factory

2008-09-23 Thread Michael Meeks

On Sat, 2008-09-20 at 00:47 -0500, Hans Petter Jansson wrote:
 Wouldn't it be possible to use a different directory, e.g.
 mail/local-index/folders.db? That would avoid both problems.

That seems like a great idea to me; at least - if the 'hot' data set of
evolution is normally just the summary information, then keeping that in
a single directory [ ie. mangle the path names into file names ] would
make it rather more likely to be contiguous on disk too which might be
nice:

~/.evolution/mail/summaries/local-Inbox-suse-kernel.db # etc. ;-)

 I still think relocating folders.db is a better option, since it would
 work for everyone without necessitating an upgrade.

Sounds best to me, if we can do it that is.

Regards,

Michael.

-- 
 [EMAIL PROTECTED]  , Pseudo Engineer, itinerant idiot


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] [opensuse-gnome] Evolution 2.22 for Factory

2008-09-22 Thread Srinivasa Ragavan
HPJ,

  HPJ, the summary can't be named like this, since, its possible that
  something like this already exists. .ibex.index has a traditional
  meaning and would be more of abusing it in the newer versions.
 
 Wouldn't it be possible to use a different directory, e.g.
 mail/local-index/folders.db? That would avoid both problems.

You end up seeing a new folder local-index in 2.22/older and a
folders.db folder under it. :(

FWIW, I did give it a try, during the initial phases, but I abandoned
it, since I was short of time.

-Srini.
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] [opensuse-gnome] Evolution 2.22 for Factory

2008-09-20 Thread Patrick Ohly
On Sat, 2008-09-20 at 00:47 -0500, Hans Petter Jansson wrote:
 Wouldn't it be possible to use a different directory, e.g.
 mail/local-index/folders.db? That would avoid both problems.

Sounds very reasonable to me. Separating user data (mbox files) and meta
data (indices) is much cleaner and simplifies things like backups of
just the relevant data. See also the Configuration masquerading Data
discussion on the Evo hackers list...

-- 
Bye, Patrick Ohly
--  
[EMAIL PROTECTED]
http://www.estamos.de/

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] [opensuse-gnome] Evolution 2.22 for Factory

2008-09-19 Thread Hans Petter Jansson
[ Adding evolution-hackers to Cc since this contains potentially useful
feedback and some questions ]

On Fri, 2008-09-19 at 18:06 +0100, Michael Meeks wrote:
 On Fri, 2008-09-19 at 00:40 -0500, Hans Petter Jansson wrote:

  Note 2: If you ran the newer version of Evolution previously, you should
  delete the sqlite database it creates before reverting to the old one -
  otherwise it will think the sqlite database is an mbox and try to index
  it, which will cause errors. Delete ~/.evolution/mail/local/folders.db*.

   That - is really bad. Can we not name our db in some way that this
 doesn't happen ? is there really no solution here ? if not, why are
 these databases in a place where older versions get confused  start
 doing stupid things ? - can we not put them somewhere else ?

That's a question for the Evo team, I guess - it looks like it could be
trivially fixed by moving the folder.db somewhere else, or calling it
folder.index or folder.ibex.index or whatever Evolution traditionally
filters out.

To Evolution's credit, my 500MB folder.db binary blob didn't cause it to
crash - it showed up as a bogus local mail folder after about 15 minutes
of disk churn - but it did throw errors whenever it needed to pull data
for vfolders.

Also, it looks like old summary/index files aren't removed - does it
require both the sqlite database and summaries now? It increases disk
space consumption quite a bit.

   Switching between versions, should work right ?

I don't know if we ever guaranteed spotless downgrading, but yeah,
having that work would be a big plus - especially since users may switch
between distros but keep their home dirs.

-- 
Hans Petter

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] [opensuse-gnome] Evolution 2.22 for Factory

2008-09-19 Thread Srinivasa Ragavan
Hello Guys,

On Fri, 2008-09-19 at 22:14 -0500, Hans Petter Jansson wrote:
 [ Adding evolution-hackers to Cc since this contains potentially useful
 feedback and some questions ]
 
 On Fri, 2008-09-19 at 18:06 +0100, Michael Meeks wrote:
  On Fri, 2008-09-19 at 00:40 -0500, Hans Petter Jansson wrote:
 
   Note 2: If you ran the newer version of Evolution previously, you should
   delete the sqlite database it creates before reverting to the old one -
   otherwise it will think the sqlite database is an mbox and try to index
   it, which will cause errors. Delete ~/.evolution/mail/local/folders.db*.
 
  That - is really bad. Can we not name our db in some way that this
  doesn't happen ? is there really no solution here ? if not, why are
  these databases in a place where older versions get confused  start
  doing stupid things ? - can we not put them somewhere else ?
 
Michael, Its n't possible to keep it there still not findable by the old
version. AFAICS, { .msf, .ev-summary, .ev-summary-meta,
.ibex.index, .ibex.index.data, .cmeta, .lock } are the possible
extensions that the old version of Evolution ignores. But these have
definite meanings and possible they exist as locks, metafiles or
old-type-summaries. Naming the new summary that way would probably erase
the real data.

 That's a question for the Evo team, I guess - it looks like it could be
 trivially fixed by moving the folder.db somewhere else, or calling it
 folder.index or folder.ibex.index or whatever Evolution traditionally
 filters out.
 

HPJ, the summary can't be named like this, since, its possible that
something like this already exists. .ibex.index has a traditional
meaning and would be more of abusing it in the newer versions.

 To Evolution's credit, my 500MB folder.db binary blob didn't cause it to
 crash - it showed up as a bogus local mail folder after about 15 minutes
 of disk churn - but it did throw errors whenever it needed to pull data
 for vfolders.
 
But, the old version shouldn't touch the folders.db automatically,
meaning the new summary would be safe, unless the user manually deletes
or adds mails to it. 

 Also, it looks like old summary/index files aren't removed - does it
 require both the sqlite database and summaries now? It increases disk
 space consumption quite a bit.

That is left purposefully. Incase you are a user switching across
versions, probably you would have to recreate summaries every time you
do. But first time, we just migrate and don't care later on. So if you
aren't a user of that category, a rm of it manually should suffice.
[probably some more summaries left on the other accounts]

 
  Switching between versions, should work right ?
 
Michael, AFAICS, it should work fine, we don't touch old summaries
written by old version. If it happens, file a bug (I dont think it
happens ):-) Just that the old version reports you of a new folder
folders.db. 

Should we ship a patch for older Evolution versions to ignore
folders.db? May be worth for power users of SLEs and RHEs, who might
still use older version  new version.

-Srini

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers