After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 552273 - Syncing should use a proper merging algorithm
Syncing should use a proper merging algorithm
Status: RESOLVED NOTGNOME
Product: tomboy
Classification: Applications
Component: General
0.12.x
Other Linux
: Low enhancement
: Future
Assigned To: Tomboy Maintainers
Tomboy Maintainers
gnome[moved-to-github]
: 483358 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-09-14 19:48 UTC by Andy Buckley
Modified: 2017-07-31 12:46 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Andy Buckley 2008-09-14 19:48:36 UTC
(Copied from https://bugs.launchpad.net/ubuntu/+source/tomboy/+bug/257108 )

When managing a set of notes between several machines, syncing should be a useful way to make sure that all the notes are the same between systems, a la SVN/CVS version control. Instead, the "merging" algorithm is just to offer to either delete the local note or rename it every time there is a remote change. This makes synchronising painful to say the least, since the changes are usually of a sort that could be seamlessly merged, again a la SVN/CVS. Instead, I end up with a load of "Note Foo"+"Note Foo (old)" pairs that really need to be merged by hand. And then attempting to sync that hand-merged note will create "Foo (old)" on all my other machines... aargh.

Synchronising notes between separate networked machines is a feature I've been waiting for for years, but Tomboy's current implementation isn't yet usable because of the propagation of backup copies to be manually merged. Using e.g. the SVN or Bazaar merging algorithm to merge remote and local copies and to highlight potential conflicts is necessary before this feature is really usable. In fact, it may even be possible to use the Python code from Bazaar to do the job... depending on how well you can handle conflicts that break XML compliance (maybe BeautifulSoup could help in resolving that situation).
Comment 1 Sandy Armstrong 2008-09-14 19:51:49 UTC
I doubt we'll ever bother doing this.  If you sync regularly when switching computers this really shouldn't be an issue.

It would be nice to have support for interactive merging, or for a popular merge algorithm (or both, whatever), and I would happily review any patches to add it, but I haven't seen much demand for our use case.
Comment 2 Andy Buckley 2008-09-14 19:55:39 UTC
Maybe the current version just isn't working for me as it should. I've tried syncing immediately on swapping machines (using SSH fuse) and I always end up with "* (old)" notes and needing to merge by hand, even with trivial changes. I've given up now, because it wasn't being useful. What _should_ happen?
Comment 3 Sandy Armstrong 2008-09-14 20:46:07 UTC
The ideal usage scenario is this:

1. Log into machine A and sync your notes.
2. Work.
3. Sync your notes and log off of machine A.
4. Log into machine B and sync your notes.
5. Work.
6. Sync your notes and log off of machine B.
7. Return to step 1 or step 4.

In theory, following this pattern, there are *never* any conflicts and no "* (old)" notes are ever created.  You should only get conflicts if you edit a note on both machines without syncing in between.

When implementing this, our opinion was that in most cases people would prefer the new note (discarding the old note), and choose the "overwrite" option instead of the "rename" option, so even then it would be rare to have "* (old)" notes.

If you think you're experiencing an actual bug in how sync works, please provide a list of reproducable steps.  It is entirely possible that you are encountering a genuine bug.  Of course, this doesn't change the fact that it would be nice to have the ability to merge when syncing.  ;-)
Comment 4 Andy Buckley 2008-10-01 13:15:18 UTC
(In reply to comment #3)
> The ideal usage scenario is this:
> 
> 1. Log into machine A and sync your notes.
> 2. Work.
> 3. Sync your notes and log off of machine A.
> 4. Log into machine B and sync your notes.
> 5. Work.
> 6. Sync your notes and log off of machine B.
> 7. Return to step 1 or step 4.

I've tried this now (using Tomboy 0.12.0 from Ubuntu Intrepid alpha6), and I think the problems I've had are because the SSH syncing often fails for no apparent (no log info in the "Details" box) reason, leaving a stuck lock file on the server. Whatever way the syncing usually terminates, if I remove the lock file by hand then even the most careful syncing fails to merge changed notes properly.

I guess this "stuck lock files" issue should be a separate bug report? I don't know why it happened, but the system should really be robust against dropped network connections, etc.

> In theory, following this pattern, there are *never* any conflicts and no "*
> (old)" notes are ever created.  You should only get conflicts if you edit a
> note on both machines without syncing in between.

In practice, I think this is an important situation to consider: users (myself included) will expect the merging to "mostly work" even if they haven't been absolutely disciplined about their syncing. Automated syncing would help to alleviate the problem, though, but there will always be times when notes are modified without a network connection and the syncing should still be able to handle merging when re-connected.

> When implementing this, our opinion was that in most cases people would prefer
> the new note (discarding the old note), and choose the "overwrite" option
> instead of the "rename" option, so even then it would be rare to have "* 
> (old)" notes.

This is probably true, but as it stands there is no way to tell what you're discarding, so I always end up taking the conservative option. Maybe a suitable interim solution would be to provide a "view differences" tab when deciding what to do. A "manually merge" option, where no "* (old)" note is created, but the whole text of both notes is copied into the local note would also be preferable to the current situation from my point of view.

> If you think you're experiencing an actual bug in how sync works, please
> provide a list of reproducable steps.  It is entirely possible that you are
> encountering a genuine bug.  Of course, this doesn't change the fact that it
> would be nice to have the ability to merge when syncing.  ;-)

Definitely! Thanks.
Comment 5 Sandy Armstrong 2008-10-01 13:26:03 UTC
(In reply to comment #4)
> I guess this "stuck lock files" issue should be a separate bug report? I don't
> know why it happened, but the system should really be robust against dropped
> network connections, etc.

Probably fixed in 0.12.0.  What version are you using?
Comment 6 Andy Buckley 2008-10-01 13:33:57 UTC
I am using 0.12.0 now (as of a few days ago) and that was what I tested your suggested merging procedure with. I've just done another Ubuntu upgrade, so will test again...
Comment 7 Andy Buckley 2008-11-03 11:45:52 UTC
Sorry about the delay --- my tests with 0.12 indicate that its SSH syncing is much more stable than previous ones. It's great to actually believe that my note syncing is likely to work without losing the conectiona nd leaving a load of stuck lock file junk on the server... thanks! I hope that this version is backported to Ubuntu 8.04 LTS, since otherwise I will have to interact with the broken syncing of the 0.10 (?) series for a long time!

However, my main request remains: merging of notes in an "unordered" way is a functionality blocker for people like me who need to sync notes from many machines without constantly being afraid that the need for strict merge ordering is going to either lose or duplicate data.
Comment 8 tvst 2009-08-05 04:47:36 UTC
It would already help a lot if you gave an option to open an application like Meld for the merging.
http://meld.sourceforge.net/
Comment 9 Jared Jennings 2011-06-25 15:51:18 UTC
*** Bug 483358 has been marked as a duplicate of this bug. ***
Comment 10 Jared Jennings 2011-06-25 15:52:41 UTC
I can see a reason for merging, but I think it would be a major change.
Comment 11 André Klapper 2017-07-31 12:46:42 UTC
The Tomboy team has moved from GNOME Bugzilla to GitHub for bug reports and feature requests: 
      https://github.com/tomboy-notes/tomboy/issues/
Closing this report as NOTGNOME as part of Bugzilla Housekeeping (bug 781054) to keep tasks in one place. Please feel free to transfer this task to GitHub if this task is still valid in a recent Tomboy version. 
We are sorry for the inconvenience.