Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up

2010-07-27 Thread Milan Crha
On Fri, 2010-07-23 at 18:08 -0400, Matthew Barnes wrote:
 For those following the master branch of git, that means that with any
 luck your ~/.evolution directory will soon be gone and you'll have far
 more control over where Evolution writes files. 

Hi,
does this mean that one would be able to keep .evolution folder as is,
with some XDG foo? You know, sometimes is useful to run 2.30.x while
developing 2.31.x on the same machine, where your change makes it
impossible.

But if it's possible, do you know the XDG foo to achieve it?
Bye,
Milan

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up

2010-07-27 Thread Matthew Barnes
On Sun, 2010-07-25 at 19:23 -0400, Matthew Barnes wrote:
 On Fri, 2010-07-23 at 18:08 -0400, Matthew Barnes wrote:
  I now have all the migration routines written and I'm fairly happy with
  them.  A few more cases to test and I think I may commit this over the
  weekend.
 
 I decided to defer this until at least Tuesday, so that those developers
 who aren't weekend workaholics like me still have some advance warning
 when they fire up their email on Monday morning.

The base directory transition is now in master.

Once again, please be mindful not to mix versions of Evolution and the
addressbook and calendar factory daemons.

The migration should be nearly instantaneous.  It's just a series of
directory renames and a few config file renames.  Each of the three
binaries will print equivalent UNIX shell commands (mv and rmdir) to
the terminal along with any errors encountered to help track migration
progress.  This output is valuable for debugging migration issues.

Please let me know immediately if you encounter any regressions.  If
there -are- regressions I expect they will be caused by Evolution not
finding some data, either because the data failed to migrate or because
Evolution is still looking for migrated data in its old home.  In either
case the data should still be present on your hard disk.


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up

2010-07-25 Thread Matthew Barnes
On Fri, 2010-07-23 at 18:08 -0400, Matthew Barnes wrote:
 I now have all the migration routines written and I'm fairly happy with
 them.  A few more cases to test and I think I may commit this over the
 weekend.

I decided to defer this until at least Tuesday, so that those developers
who aren't weekend workaholics like me still have some advance warning
when they fire up their email on Monday morning.

Also, I plan to merge one of Srini's branches tonight with some exciting
new features for Express mode.  That's gonna kick up some dust that will
need to settle before I drop the next bombshell.

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up

2010-07-24 Thread Matthew Barnes
On Sat, 2010-07-24 at 07:48 +0200, Yves-Alexis Perez wrote:
 An an evolution user and a packager, is this really a good idea?
 Shouldn't it be safer to keep it “as a backup” but mark it as already
 migrated. This way, another attempt can be tried should the first one
 fail, and we don't touch user valuable data.

Are you suggesting we copy the data instead of moving it?  That could be
a -lot- of data.  It also runs a higher risk of failure since the user's
hard drive may not have enough free space for a copy.  The migration at
present is just a scripted sequence of rename() and rmdir() commands.

The problem is we have three binaries writing data there.  Two of those
have no user interface, and may start long before you launch Evolution
itself.  So the migration needs to happen in phases, and I don't see a
way to warn the user ahead of time.  By the time you start Evolution,
the data may already be 2/3 migrated by the D-Bus services.

That said, I'm open to ideas for making the process safer.  Especially
for the case where the user tries to downgrade and then panics because
Evolution suddenly can't find his data.  Should Evolution present a big
scary warning at startup if it sees (from GConf) that a later version
was previously run?

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers