On Thu, Jun 11, 2015 at 08:47:16PM +0200, Robert C. Helling wrote: > > > So you are our posterchild for then implementing merging :-) > > that may be way beyond my powers.
I realized that I phrased this badly. No, I'm not saying you need to implement that. What I'm saying is "you need to help bully Linus into implementing that" :-) > But I promise I will think about this and try to come up with something. > Somehow, we might make use of the fact that our files have more > structure than just line numbers, namely they are xml fields. When Linus and I talked about the git file format a couple of years ago a big part of the way this was designed was to make a lot of the typical scenarios easy to merge. You edit dives on one devices. You add new dives on another one. That is a trivial merge with our git format. Even things like "you edit the dive notes for dive 3 on this device and you download dive 3 again from a different dive computer on another device" are trivial to merge. You edit the same data for the same dive on two devices. Yeah, that's still hard. But I think the vast majority of the things that the average user is likely to do should be rather straight forward to implement. > One somehow simple way do deal with conflicts would be to try to be as > clever as possible with the three way merge and if that fails work on a > “per dive” basis, i.e. just have the both versions of the dive show up > in the dive list (maybe marked somehow) and let the user figure it out. I think this should almost never be necessary. Unless, of course, you TRY to make things hard :-) > Given that dives in the git format are files (or actually directories), > what happens when in one version a dive is modified and in a separate > version it is deleted? Is that detected as a conflict? (probably) How > should we present that? Yes, that's one of those cases that would require human interaction. Or you could go by time stamp and simply always accept the newer transaction :-) /D _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
