Here we go http://cgit.collabora.com/git/user/cassidy/telepathy-mission-control/log/?h=butterfly-migration-42814

(In reply to comment #1)
> Here we go
> http://cgit.collabora.com/git/user/cassidy/telepathy-mission-control/log/?h=butterfly-migration-42814

     release_load_accounts_lock (lad);
+
+    migrate_accounts (account_manager);

I think you want to take an account lock for each account being migrated, and release each one when the migration succeeds or fails; and call migrate_accounts() before this call to release_load_accounts_lock().

account_lock is used to stop the account manager appearing on the bus until all the accounts are loaded up and ready to go. Presumably we want the migration to happen before MC appears on the bus? (With this branch at present, that's not the case.)

It would be nice to annotate the new accounts with some indicator of the account path they replace.

(In reply to comment #2)
> (In reply to comment #1)
> > Here we go
> > http://cgit.collabora.com/git/user/cassidy/telepathy-mission-control/log/?h=butterfly-migration-42814
> 
>      release_load_accounts_lock (lad);
> +
> +    migrate_accounts (account_manager);
> 
> I think you want to take an account lock for each account being migrated, and
> release each one when the migration succeeds or fails; and call
> migrate_accounts() before this call to release_load_accounts_lock().
> 
> account_lock is used to stop the account manager appearing on the bus until all
> the accounts are loaded up and ready to go. Presumably we want the migration to
> happen before MC appears on the bus? (With this branch at present, that's not
> the case.)

Good point. I've done that in a new patch.

> It would be nice to annotate the new accounts with some indicator of the
> account path they replace.

We should either add a Account.Replace (as) or Account.Misc a{sv} property to do so.

(In reply to comment #3)
> We should either add a Account.Replace (as) 

I meant: Account.Replace (ao)

Do we really want to know which account it comes from? The only one potentially interested about this information is the logger but it's not going to do any migration anyway. The general idea is that the logger's API should be "protocol + account id" oriented rather than using a specific account. See https://bugs.freedesktop.org/show_bug.cgi?id=42917

I'd really like to get this branch merged as Butterfly will just not work with Empathy 3.4

We have 3 options:
a) Add Account.Replace (ao)
b) Add Account.Misc a{sv}
c) Decide we don't care and keep the branch as it.

Either way if fine for me as long as we get this thing done.

Note that b) could be useful to also solve the "account id" problem in the logger with IRC: https://bugs.freedesktop.org/show_bug.cgi?id=42917#c12

Butterfly won't work at all with Empathy 3.4 so my migration branch will be merged before the end of the week (string/ui freeze). The MC one should be as well, but we still have the problem of old logs.

The proper fix is to change logger's API to make it "login id" centric rather than account centric, but that's a pretty big change and I don't see it happening now.

So either we decide to not care about old logs (losing logs is a less bad solution than keeping an unworking TP account) or do a hack to continue displaying them. The only hack I can think of is storing the information about the old account in the new one (Account.Replace or Account.Misc) and use it in liblogger when fetching logs.

Either way is fine for me, MSN has always been a second class citizen in Empathy so maybe loosing logs (from an end user pov, log file won't be deleleted) isn't *that* bad after all.

(In reply to comment #7)
> So either we decide to not care about old logs (losing logs is a less bad solution than keeping an unworking TP account) or do a hack to continue displaying
> them. The only hack I can think of is storing the information about the old account in the new one (Account.Replace or Account.Misc) and use it in liblogger
> when fetching logs.

I think Account.Replaces or Account.ReplacementFor (an ao, either way) is reasonable. Maiku wants a spec release soon anyway, for Captcha1 (Bug #32125).

Spec:
http://cgit.freedesktop.org/~smcv/telepathy-spec/log/?h=account-supersedes

tp-glib (the TEMPORARY commit will go away with the new spec):
http://cgit.freedesktop.org/~smcv/telepathy-glib/log/?h=supersedes

MC (based on your branch, migration tested manually):
http://cgit.freedesktop.org/~smcv/telepathy-mission-control/log/?h=butterfly-migration-42814

All good to me.

Fixed in git for 5.11.0