Re: migrating to new backend format

[Chipzz <chipzz ULYSSIS Org>]

On 5 Oct 2003, Havoc Pennington wrote:

> From: Havoc Pennington <hp redhat com>
> Subject: Re: migrating to new backend format
>
> On Sun, 2003-10-05 at 16:12, seth vidal wrote:
> > How do you resolve conflicts b/t them? Does one win over the other?
> >
>
> Yes, it's a path search, now we have:
>  mandatory -> ~/.gconf -> defaults
> we could do:
>  mandatory -> ~/.gconf26 -> ~/.gconf -> defaults
>
> with the twist that ~/.gconf remains writable which means that key
> deletions remove the key from both ~/.gconf26 and ~/.gconf. However key
> writes (new values) go only to ~/.gconf26 (as currently coded, IIRC), so
> if you just _set_ a new value, it changes ~/.gconf26 and leaves ~/.gconf
> alone.
>
> It's a bit hard to know how this would behave, so I'm leaning against
> it.

So, the answer to the question that remained unanswered in my mail, ie
as to what to do wrt synchronizing the 2 trees is essentially, "We
don't, we migrate the gconf 2.4 settings to the new format on a per-need
basis and keep lingering the old tree lingering around in case the user
wants to go back.", which leaves the old tree with possibly incorrect
settings.
As most users won't go back anyway, I don't see much difference with the
other option of just migrating the tree on the first run, and popping up
a question weither to delete the old tree or not. Question is of course
_what_ should display that setting. I think the answer is to provide 2
migration scripts, one forward and one backward, and let gnome-session
or gnome-settings-daemon run it.

kr,

Chipzz AKA
Jan Van Buggenhout
-- 

------------------------------------------------------------------------
                 UNIX isn't dead - It just smells funny
                           Chipzz ULYSSIS Org
------------------------------------------------------------------------