2:13 a.m.
http://bugzilla.moblin.org/show_bug.cgi?id=8144
Summary: D-Bus API: restore backups
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: normal
Priority: P1
Component: *Feature Request
AssignedTo: syncevolution(a)lists.intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
We have not specified a D-Bus API for restoring data from one of our automatic
backups.
This should be modeled after the corresponding command line feature:
Restore data from the automatic backups:
syncevolution --restore <session directory> --before|--after [--dry-run]
<server> <source> ...
--restore
Restores the data of the selected sources to the state from before or after
the
selected synchronization. The synchronization is selected via its log
directory
(see --print-sessions). Other directories can also be given as long as
they contain database dumps in the format created by SyncEvolution.
The output includes information about the changes made during the
restore, both in terms of item changes and content changes (which is
not always the same, see manual for details). This output can be suppressed
with --quiet.
In combination with --dry-run, the changes to local data are only simulated.
This can be used to check that --restore will not remove valuable
information.
We also have to extend reports such that a D-Bus client can determine which
kind of backups are available.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
2:14 a.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |7210, 8050
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
6:22 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
yongsheng zhu <yongsheng.zhu(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |yongsheng.zhu(a)intel.com
AssignedTo|syncevolution(a)lists.intel.c |yongsheng.zhu(a)intel.com
|om |
--- Comment #1 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-10 23:22:50 PST
---
assign to me
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
4:51 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #2 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-13 21:51:34 PST
---
Here is the API description:
<method name="Restore">
<doc:doc><doc:description>
Restores the data of the selected sources to the state from before or
after the selected synchronization. The synchronization is selected via its log
directory. Other directories can also be given as long as they contain database
dumps in the format created by SyncEvolution. The output includes information
about the changes made during the restore, both in terms of item changes and
content changes.
When "sources" are empty, it assumes to restore all available backup
sources in the session. If a source is not found in the backup database, then
an exception is thrown.
</doc:description></doc:doc>
<arg type="s" name="dir" direction="in">
<doc:doc><doc:summary>log directory for the
session</doc:summary></doc:doc>
</arg>
<arg type="b" name="before" direction="in">
<doc:doc><doc:summary>restore to the data before or after the
session</doc:summary></doc:doc>
</arg>
<arg type="as" name="sources" direction="in">
<doc:doc><doc:summary>sources list that be needed to
restore</doc:summary></doc:doc>
<doc:doc><doc:description>Valid values are all available
sources.</doc:description></doc:doc>
</arg>
</method>
My concern is that we don't send an ID( or log directory) to dbus clients in
Session.GetReports(). I think an entry should be added in the report dict. so
a pair of <"dir", log dir> is likely to be inserted into the dict if no
objection.
Jussi, you said, "I see I get backup identifiers from the sync reports". I
don't know which key you refer to in the reports.
What should happen after the restore? A refresh from client?
I
think so. This seems reasonable to me. But I assume the dbus client will call
Session.Sync() explictly in refresh-from-client mode.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
11:43 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
jku <jku(a)linux.intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jku(a)linux.intel.com
--- Comment #3 from jku <jku(a)linux.intel.com> 2009-12-14 04:43:05 PST ---
Which object is this method in? I'm assuming Session.
(In reply to comment #2)
The output includes information about the changes made during the
restore,
both in terms of item changes and content changes.
This is not visible in the API :)
We need to decide on return values, as well as status notifications.
Some ideas/questions:
* Could this be considered a sort of "sync" with regard to
status changes, return values and sync reports? There may be good reasons
to not do that, but that was the first idea I had...
* In any case you can probably reuse the sync report format at least partly?
My concern is that we don't send an ID( or log directory) to dbus
clients in
Session.GetReports(). I think an entry should be added in the report dict. so
a pair of <"dir", log dir> is likely to be inserted into the dict if no
objection.
Clients need to get the identifiers from server but whether that identifier is
a real directory is a server implementation detail as far as I'm concerned.
Jussi, you said, "I see I get backup identifiers from the sync
reports". I
don't know which key you refer to in the reports.
I'm seeing keys like "source-todo-backup-after" with uint values. I just
guessed they were backup identifiers.
> What should happen after the restore? A refresh from client?
I think so. This seems reasonable to me. But I assume the dbus client will
call Session.Sync() explictly in refresh-from-client mode.
Agreed.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
1:09 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #4 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-14 18:09:14 PST
---
(In reply to comment #3)
Which object is this method in? I'm assuming Session.
right.
(In reply to comment #2)
> The output includes information about the changes made during the restore,
> both in terms of item changes and content changes.
This is not visible in the API :)
ok, I'll remove this statement out of the API
document.
We need to decide on return values, as well as status notifications.
Some ideas/questions:
* Could this be considered a sort of "sync" with regard to
status changes, return values and sync reports? There may be good reasons
to not do that, but that was the first idea I had...
* In any case you can probably reuse the sync report format at least partly?
I
think at least 'restore' won't provide this kind of thing since it doesn't
do
any sync related things with server, but after restoring, a call of
Session.Sync() could provide them.
Patrick, any comments?
> My concern is that we don't send an ID( or log directory) to
dbus clients in
> Session.GetReports(). I think an entry should be added in the report dict. so
> a pair of <"dir", log dir> is likely to be inserted into the dict if
no
> objection.
Clients need to get the identifiers from server but whether that identifier is
a real directory is a server implementation detail as far as I'm concerned.
ok,
but the key should be specified. so the name is 'dir', ok?
> Jussi, you said, "I see I get backup identifiers from the
sync reports". I
> don't know which key you refer to in the reports.
I'm seeing keys like "source-todo-backup-after" with uint values. I just
guessed they were backup identifiers.
no, that's just the number of items after
sync. We'll use 'dir' as identifiers,
see the above.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
8:27 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #5 from pohly <patrick.ohly(a)intel.com> 2009-12-15 01:27:43 PST ---
(In reply to comment #4)
(In reply to comment #3)
> Which object is this method in? I'm assuming Session.
right.
> (In reply to comment #2)
> > The output includes information about the changes made during the restore,
> > both in terms of item changes and content changes.
>
> This is not visible in the API :)
ok, I'll remove this statement out of the API document.
> We need to decide on return values, as well as status notifications.
> Some ideas/questions:
> * Could this be considered a sort of "sync" with regard to
> status changes, return values and sync reports? There may be good reasons
> to not do that, but that was the first idea I had...
> * In any case you can probably reuse the sync report format at least partly?
I think at least 'restore' won't provide this kind of thing since it
doesn't do
any sync related things with server,
A "restore" does provide a minimal pseudo-sync report:
$ syncevolution --before --restore
/home/pohly/.cache/syncevolution/scheduleworld__1-2009-12-15-10-23-1
scheduleworld_1 vcard30
[INFO] Item changes that were applied to client during restore:
+-------------------------------------|-----------ON CLIENT-----------+
| | rejected / total |
| Source | NEW | MOD | DEL | TOTAL |
+-------------------------------------+-------+-------+-------+-------+
| vcard30 | 0/17 | 0/0 | 0/1 | 0/34 |
+-------------------------------------+-------+-------+-------+-------+
[INFO] The same incremental changes will be applied to the server during the
next sync.
[INFO] Use -sync refresh-from-client to replace the complete data on the
server.
It reuses the same SyncReport with slightly different semantic (no information
about server, changes applied locally are triggered by restore instead of the
peer).
but after restoring, a call of
Session.Sync() could provide them.
That looks like a reasonable way of providing the information. The question
remains whether the restore call should be synchronous (when it completes, the
restore is done) or asynchronous (call starts the operation, completes later).
I think it should be asynchronous, to avoid D-Bus timeouts.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
2:02 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #6 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-15 19:02:22 PST
---
A "restore" does provide a minimal pseudo-sync report:
yes, but it won't generate a new session directory, right?
It reuses the same SyncReport with slightly different semantic (no
information
about server, changes applied locally are triggered by restore instead of the
peer).
so Jussi, which way do you prefer to give status and report info? add a
parameter or use status signal?
> but after restoring, a call of
> Session.Sync() could provide them.
That looks like a reasonable way of providing the information. The question
remains whether the restore call should be synchronous (when it completes, the
restore is done) or asynchronous (call starts the operation, completes later).
I think it should be asynchronous, to avoid D-Bus timeouts.
Patrick, is this method
the same as the way 'Session.Sync()' does? 'Restore' is
just to do some operations on local databases(Session.sync() will be called
explictly after restoring). Is it really necessary to call it asynchronously?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:34 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #7 from pohly <patrick.ohly(a)intel.com> 2009-12-15 23:34:33 PST ---
(In reply to comment #6)
> A "restore" does provide a minimal pseudo-sync
report:
yes, but it won't generate a new session directory, right?
Correct.
> > but after restoring, a call of
> > Session.Sync() could provide them.
>
> That looks like a reasonable way of providing the information.
No, wait. I wasn't paying enough attention. What I meant was that the Session
instance could remember the pseudo-sync report and buffer it to be queried by
the D-Bus client(s). However, we don't have such an API, have we?
Calling Session.Sync() after a Restore() makes no sense.
> The question
> remains whether the restore call should be synchronous (when it completes, the
> restore is done) or asynchronous (call starts the operation, completes later).
> I think it should be asynchronous, to avoid D-Bus timeouts.
Patrick, is this method the same as the way 'Session.Sync()' does?
'Restore' is
just to do some operations on local databases(Session.sync() will be called
explictly after restoring). Is it really necessary to call it asynchronously?
These "local" operations might do network operations (see new XMLRPC backend)
or potentially move a lot of data via D-Bus to EDS. I expect that this can be
slow.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:56 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #8 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-15 23:56:17 PST
---
No, wait. I wasn't paying enough attention. What I meant was that
the Session
instance could remember the pseudo-sync report and buffer it to be queried by
the D-Bus client(s). However, we don't have such an API, have we?
no, we
don't. But just like Jussi said(if i'm not mis-understood him), we may
use the status signals to notify reports. If this is true, SyncContext::restore
has to be modified to send events, like the really 'sync'.
Calling Session.Sync() after a Restore() makes no sense.
right.
> > The question
> > remains whether the restore call should be synchronous (when it completes, the
> > restore is done) or asynchronous (call starts the operation, completes later).
> > I think it should be asynchronous, to avoid D-Bus timeouts.
> Patrick, is this method the same as the way 'Session.Sync()' does?
'Restore' is
> just to do some operations on local databases(Session.sync() will be called
> explictly after restoring). Is it really necessary to call it asynchronously?
These "local" operations might do network operations (see new XMLRPC backend)
or potentially move a lot of data via D-Bus to EDS. I expect that this can be
slow.
reasonable. Then I'd like to reuse 'run' method and add a
'enum' value to
decide whether it really need do what.
void Session::run()
{
if(m_sync) {
switch(m_operation) {
case SYNC:
// do something
case RESTORE:
// do restore
};
}
In Session.Restore(), it only creates a new sync and then it could trigger a
restore operation.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
7:28 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #9 from pohly <patrick.ohly(a)intel.com> 2009-12-16 00:28:39 PST ---
(In reply to comment #8)
> These "local" operations might do network operations
(see new XMLRPC backend)
> or potentially move a lot of data via D-Bus to EDS. I expect that this can be
> slow.
reasonable. Then I'd like to reuse 'run' method and add a 'enum'
value to
decide whether it really need do what.
void Session::run()
{
if(m_sync) {
switch(m_operation) {
case SYNC:
// do something
case RESTORE:
// do restore
};
}
In Session.Restore(), it only creates a new sync and then it could trigger a
restore operation.
This looks reasonable. Jussi, should completion be signaled using the normal
"StatusChanged done" mechanism?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
9:19 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #10 from jku <jku(a)linux.intel.com> 2009-12-16 02:19:16 PST ---
(In reply to comment #6)
> > > but after restoring, a call of
> > > Session.Sync() could provide them.
> >
> > That looks like a reasonable way of providing the information.
No, wait. I wasn't paying enough attention. What I meant was that the Session
instance could remember the pseudo-sync report and buffer it to be queried by
the D-Bus client(s). However, we don't have such an API, have we?
Calling Session.Sync() after a Restore() makes no sense.
This was a misunderstanding: Yongsheng and I were talking about the client
synchronizing after restore, Patrick was talking about getting a report of the
restore itself... Doing a sync for the former makes sense, doing one for the
latter does not. Two comments on restore reports:
1. I don't think I absolutely need to get report type information after the
sync: logically I will be syncing with the server right after the report, and
that report is what I believe the user wants to see.
2. If the restore can take a long time, getting progress info during the
restore would be nice, of course. I'm mostly talking about a percentage
estimate here: anything else is bonus and might not even be used.
2. Seeing the "diff" statistics before the restore would of course be useful,
but I bet it's not that simple...
I would like Status changes (including "done") though: this way I can just use
the same code that handles syncs. Patrick pointed out that Session should not
automatically close after a Restore() and that makes sense to me as well.
Like I said, progress indication would be even better if a restore can
potentially take a while, but I don't see that as required.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
9:20 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #11 from jku <jku(a)linux.intel.com> 2009-12-16 02:20:35 PST ---
(In reply to comment #10)
Two comments on restore reports:
...for very large values of two.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
1:28 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #12 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-16 18:28:38
PST ---
This was a misunderstanding: Yongsheng and I were talking about the
client
synchronizing after restore, Patrick was talking about getting a report of the
restore itself... Doing a sync for the former makes sense, doing one for the
latter does not. Two comments on restore reports:
1. I don't think I absolutely need to get report type information after the
sync: logically I will be syncing with the server right after the report, and
that report is what I believe the user wants to see.
good, then Session.Restore
doesn't return any report info but UI gets the
report of later syncing. so Restore API get unchanged.
2. If the restore can take a long time, getting progress info during
the
restore would be nice, of course. I'm mostly talking about a percentage
estimate here: anything else is bonus and might not even be used.
Percentage here
might be hard to estimate and it is only a rough data. IMHO, it
might be based on source level at least now. That means it can't calculate the
progress inside one source restoring.
2. Seeing the "diff" statistics before the restore would of
course be useful,
but I bet it's not that simple...
I would like Status changes (including "done") though: this way I can just use
the same code that handles syncs. Patrick pointed out that Session should not
automatically close after a Restore() and that makes sense to me as well.
ok,
I'll follow this way to send StatusChanged signals.
Like I said, progress indication would be even better if a restore
can
potentially take a while, but I don't see that as required.
Yes, it would be
nicer to have progress info. see above.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:48 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #13 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-16 23:48:07
PST ---
void Session::run()
{
if(m_sync) {
switch(m_operation) {
case SYNC:
// do something
case RESTORE:
// do restore
};
}
In Session.Restore(), it only creates a new sync and then it could trigger a
restore operation.
There is another problem. Once Session.run() is done, the
session is set as
inactive and can't be called again according to session management in
DBusServer.run(). However, for restore, firstly call Session.restore(), which
will make the session inactive once Session.run(). Right after that, a
Session.sync() is needed. So current impl makes no sense.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
7:42 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #14 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-17 00:42:37
PST ---
(In reply to comment #13)
> void Session::run()
> {
> if(m_sync) {
> switch(m_operation) {
> case SYNC:
> // do something
> case RESTORE:
> // do restore
> };
> }
> In Session.Restore(), it only creates a new sync and then it could trigger a
> restore operation.
There is another problem. Once Session.run() is done, the session is set as
inactive and can't be called again according to session management in
DBusServer.run(). However, for restore, firstly call Session.restore(), which
will make the session inactive once Session.run(). Right after that, a
Session.sync() is needed. So current impl makes no sense.
so two alternatives:
1) dbus clients create a new session to do sync
2) dbus handles this: I'd like to change the return value of Session.run from
'void' to 'bool'. If false, remove the session and make it inactive. If
true,
still let it active.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
8:16 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #15 from jku <jku(a)linux.intel.com> 2009-12-17 01:16:20 PST ---
(In reply to comment #14)
so two alternatives:
1) dbus clients create a new session to do sync
2) dbus handles this: I'd like to change the return value of Session.run from
'void' to 'bool'. If false, remove the session and make it inactive. If
true,
still let it active.
Either way works for me as would
3) sessions are only closed on request
That does leave some room for stupid clients to mess up, but I can do that by
opening a session and not doing anything anyway...
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
4:41 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #16 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-17 21:41:15
PST ---
(In reply to comment #15)
(In reply to comment #14)
> so two alternatives:
> 1) dbus clients create a new session to do sync
> 2) dbus handles this: I'd like to change the return value of Session.run from
> 'void' to 'bool'. If false, remove the session and make it inactive.
If true,
> still let it active.
Either way works for me as would
If 1) is ok for you, I prefer it for it simplizes
the logic of dbus server.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
9:02 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #17 from jku <jku(a)linux.intel.com> 2009-12-18 02:02:39 PST ---
(In reply to comment #16)
If 1) is ok for you, I prefer it for it simplizes the logic of dbus
server.
I can deal with any solution here so go ahead.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:30 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #18 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-20 23:30:08
PST ---
(In reply to comment #17)
(In reply to comment #16)
> If 1) is ok for you, I prefer it for it simplizes the logic of dbus server.
I can deal with any solution here so go ahead.
Restore is available on my branch
'yongsheng'. I'll merge it to master after
review. But without 2 features:
1) progress related info: will be done in next 2 days
2) Seeing the "diff" statistics before the restore would of course be useful,
I guess the "diff" statistics you said here is the difference between data in
current backend and the selected restore session?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:35 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #19 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-20 23:35:36
PST ---
> I can deal with any solution here so go ahead.
Restore is available on my branch 'yongsheng'. I'll merge it to master after
review.
Congwu, could you please review it?
http://git.moblin.org/cgit.cgi/syncevolution/log/?h=yongsheng
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
12:22 a.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #20 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-21 05:22:27
PST ---
(In reply to comment #19)
> > I can deal with any solution here so go ahead.
> Restore is available on my branch 'yongsheng'. I'll merge it to master
after
> review.
Congwu, could you please review it?
http://git.moblin.org/cgit.cgi/syncevolution/log/?h=yongsheng
refine according to Congwu's comments.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
1:47 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
Chen Congwu <congwu.chen(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |congwu.chen(a)intel.com
--- Comment #21 from Chen Congwu <congwu.chen(a)intel.com> 2009-12-21 18:47:04 PST
---
(In reply to comment #20)
Looks good to me, please merge
(In reply to comment #19)
> > > I can deal with any solution here so go ahead.
> > Restore is available on my branch 'yongsheng'. I'll merge it to
master after
> > review.
> Congwu, could you please review it?
> http://git.moblin.org/cgit.cgi/syncevolution/log/?h=yongsheng
refine according to Congwu's comments.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
1:51 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #22 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-21 18:51:55
PST ---
Restore is available on my branch 'yongsheng'. I'll merge
it to master after
review. But without 2 features:
1) progress related info: will be done in next 2 days
For progress related info, a
virtual function is needed for SyncContext to let
'restore' report its progress. 2 alternatives:
1) reuse 'displaySourceProgress()'
2) create a new function 'displayRestoreProgress()'
The first one makes the SyncContext clear. I'd like to reuse it.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
1:54 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #23 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-21 18:54:51
PST ---
2) Seeing the "diff" statistics before the restore would of
course be useful,
I guess the "diff" statistics you said here is the difference between data in
current backend and the selected restore session?
Jussi, what's the 'diff' statistics here?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
5:47 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #24 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-21 22:47:35
PST ---
(In reply to comment #22)
> Restore is available on my branch 'yongsheng'. I'll
merge it to master after
> review. But without 2 features:
> 1) progress related info: will be done in next 2 days
For progress related info, a virtual function is needed for SyncContext to let
'restore' report its progress. 2 alternatives:
1) reuse 'displaySourceProgress()'
2) create a new function 'displayRestoreProgress()'
The first one makes the SyncContext clear. I'd like to reuse it.
If reuse
'displaySourceProgress()' to report progress,
SyncContext::displaySourceProgress will generate output messages according to
source's sync mode. To be confirmed, I'll create a new pseudo sync mode
'SYNC_RESTORE_FROM_BACKUP' to indicate the source is going to be restored.
Also, restore related message will also be generated in
SyncContext::displaySourceProgress.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
4:03 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #25 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2009-12-27 21:03:08
PST ---
all are merged except for 'diff' stat.
waiting for Jussi's input.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
1:24 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #26 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-01-19 18:24:36
PST ---
Jussi, do you have any comments?
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
2:05 a.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #27 from jku <jku(a)linux.intel.com> 2010-01-25 07:05:24 PST ---
(In reply to comment #25)
all are merged except for 'diff' stat.
waiting for Jussi's input.
Oh, sorry.
When I said 'diff' I meant the difference to current backend contents (and I
realise that it's not exactly an easy, or maybe even possible, request). What
I'm really looking for is a ways to give the user some insight into how
extensive changes are going to happen when he presses "Restore", but this is
not crucial... I guess I could sum up the changes in all reports up to that
point but I'm not sure if that would be useful?
I've got the restores working in the UI now, will push to jku today or
tomorrow.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
12:39 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #28 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-01-25 17:39:31
PST ---
(In reply to comment #27)
(In reply to comment #25)
> all are merged except for 'diff' stat.
> waiting for Jussi's input.
Oh, sorry.
When I said 'diff' I meant the difference to current backend contents (and I
realise that it's not exactly an easy, or maybe even possible, request). What
I'm really looking for is a ways to give the user some insight into how
extensive changes are going to happen when he presses "Restore", but this is
not crucial... I guess I could sum up the changes in all reports up to that
point but I'm not sure if that would be useful?
This may be hard. Is it
possible to compare the session data with the current
backend contents directly? I know for each session, we have the saved data not
only the difference between the previous session.
I've got the restores working in the UI now, will push to jku
today or
tomorrow.
good, thanks.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
6:02 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
--- Comment #29 from pohly <patrick.ohly(a)intel.com> 2010-01-25 23:01:32 PST ---
(In reply to comment #28)
(In reply to comment #27)
> (In reply to comment #25)
> > all are merged except for 'diff' stat.
> > waiting for Jussi's input.
>
> Oh, sorry.
>
> When I said 'diff' I meant the difference to current backend contents (and
I
> realise that it's not exactly an easy, or maybe even possible, request). What
> I'm really looking for is a ways to give the user some insight into how
> extensive changes are going to happen when he presses "Restore", but this
is
> not crucial... I guess I could sum up the changes in all reports up to that
> point but I'm not sure if that would be useful?
This may be hard. Is it possible to compare the session data with the current
backend contents directly?
Yes. There is a "dry-run" mode in the command line which initiates a restore
without actually writing anything. In this mode we get
- the same statistics about updated/removed/added items as for a real restore
- a synccompare diff
I think the former is what Jussi wants. But it is not cheap.
I suggest that we add a "dry-run" flag to the restore call. We can throw a
"not
implemented" error when it is set, but we should at least get it into the API.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
8:18 p.m.
New subject: [Bug 8144] D-Bus API: restore backups
http://bugzilla.moblin.org/show_bug.cgi?id=8144
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--- Comment #30 from pohly <patrick.ohly(a)intel.com> 2010-02-04 01:18:54 PST ---
Let's test as normal functional testing.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.
4609
days inactive
4682
days old
syncevolution-issues@syncevolution.org
31 comments
1 participants
participants (1)
-
bugzilla＠moblin.org