So based on Linus' comments about the potential risks with my merge
stategy in the case of multi line dive notes I went out to write a test
case that showed how things were breaking and then planned to fix what got
damaged.
I'll push the test that I wrote soon, the basic idea was to have three
dives which started with identical multi line notes:
Create multi line dive notes
Line 2
Line 3
Line 4
Line 5
That should be enough
And then modify them offline to read
Create multi line dive notes
Different line 2 and removed 3-5
That should be enough
and
Line 2
Line 3
Line 4
Line 5
and
single line dive notes
And modify the cloud repository to contain
Completely different dive notes
But also multi line
and
single line dive notes
and
Line 2
Line 3
Line 4
Line 5
I'm not sure if maybe I just didn't hit the right weird cases, but this
all merged perfectly (and I define this as "no problems parsing the data
and the result is at least consistent".
The three dives (when looking at the git repo cache) now contain this:
notes "Create multi line dive notes
Different line 2 and removed 3-5
That should be enough"
notes "Completely different dive notes
But also multi line"
and
notes "Line 2
Line 3
Line 4
Line 5"
notes "single line dive notes"
and
notes "single line dive notes"
notes "Line 2
Line 3
Line 4
Line 5"
So the merge added both notes fields completely. And when written back
out, in each case simply the second set of notes is picked.
Now one could argue we should keep both - I don't know what's best... but
I'm rather surprised that git kept the strings intact and didn't create
anything that would cause us a parsing error.
Cool. Another worry off my list :-)
/D
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
