syncing two pcs

Tue Jul 8 16:11:16 EDT 2008

On Tue, Jul 08, 2008 at 02:11:40PM -0400, Donald Allen wrote:
> On Tue, Jul 8, 2008 at 10:25 AM, Manfred Usselmann
> <usselmann.m at icg-online.de> wrote:
> > On Tue, 8 Jul 2008 09:17:28 -0400
> > "Donald Allen" <donaldcallen at gmail.com> wrote:
> >
> >> On Tue, Jul 8, 2008 at 8:40 AM, Mike or Penny Novack
> >> <stepbystepfarm at mtdata.com> wrote:
> >> > Flynn, Oweson O wrote:
> >> >
> >> >>I have found a stunning app for M$ Windows, that allows you to
> >> >>synchronise both ways - it shows you which one is newer, can show
> >> >>you only differences - well worth a look at - it will allow you to
> >> >>keep your copy of your data file synchronised.
> >> >>
> >> >>I use it to sync the Outlook PST mail files between my work machine
> >> >>and my home PC - I copy the files onto a USB drive, and use it to
> >> >>update the older copy (which ever one that is).
> >> >>
> >> >>The App is called 'Beyond Compare 2' - go look at
> >> >>http://www.scootersoftware.com/
> >> >>
> >> >>Hope this helps!
> >> >>
> >> >>
> >> > Misconception? Misunderstanding/disagreement about the term "newer".
> >> >
> >> > In the third example I was NOT meaning to imply that a program
> >> > could not be written to do exactly what you just described. Use
> >> > "time stamp" to mediate the decision about which version/changes to
> >> > use. Thus the program would always give a definite result (the
> >> > result of the PARTICULAR merge would be defined, reproducible). The
> >> > problem is however that we are dealing with ASYNCHRONOUS events.
> >> > Real time isn't meaningful, just "states".
> >> >
> >> > We start with one version of the data (initial state). We give this
> >> > to two DISCONNECTED processes which can make changes. Afterwards we
> >> > meant to return to one version of the data. It doesn't/shouldn't
> >> > matter which process changed what and when during the time interval
> >> > of separation. In general "which happens first" (which is SUPPOSED
> >> > to happen first) is not well defined. That can be true even if the
> >> > processes are running on the same multitasking computer --- it is
> >> > what "queue on sharable resource" mechanisms are designed to
> >> > mediate.
> >> >
> >> > Imagine the following scenario. A (text) document is given to two
> >> > workers to edit with instructions "get this job done by the end of
> >> > the day". At this point your "merge" application is supposed to
> >> > operate. You expect anything other than gobbly-gook for the result?
> >> > You expect changes not to be lost? You are willing to accept
> >> > different results depending upon when during the day the two
> >> > workers chose to tackle their assignment? Understand now? While
> >> > using something of the sort you describe would produce well defined
> >> > results in terms of a PARTICULAR data merge it would not produce a
> >> > defined resulting text from the defined "assignment" (if you tried
> >> > again, since the two workers might next time choose different times
> >> > during the day to perform the assigned task, the results would not
> >> > be the same).
> >>
> >> Ever used CVS? It allows precisely the scenario you hypothesize, and
> >> does the merge without losing any changes, flagging lexical conflicts.
> >> Of course, it can't detect logical conflicts in simultaneous code
> >> changes, but that's not what you were talking about.
> >
> > As I understand it, that's exactly what he is talking about: Automatic
> > merging is not always possible due to logical conflicts caused by
> > independent, parallel changes of the same thing.
> 
> What you say is true. He said something stronger: "At this point your
> "merge" application is supposed to operate. You
> expect anything other than gobbly-gook for the result? You expect
> changes not to be lost?"
> 
> CVS merge neither results in "gobbledy-gook" nor are changes lost.

Most revision management systems (of which CVS is one, albeit obsolete 
by now) compare files line by line.  Here;s a typical scenario.

Start with original document O.

Arnold edits it and gets document A.
Beth edits it and gets document B.

Now we need to merge.

CVS will calculate which lines have to be insertedm deleted or replaced 
to make document O into A.  It then does the same to figure how to 
convert O into B.  THen it applies both sets of changes to convert O 
into C, which is the merged document.

It fails when the two sets of changes conflict.  In this case, Arnold 
and Beth will have to reconcile the conflicts by hand to get a 
consistent document.

Now these conflicting changes are'nt the real problem.  They are 
detected, and presumably can be handled by hand.

The problem ins using something like CVS for Gnucash is that they 
accomplish line by line.  In general, even for programming, where these 
systems are most often used, they do not necessarily preserve the syntax 
of the original code. Program syntax inposes constraints that go beyond 
the validity of individual lines.  It the text is conprehensible to 
the human beings that were editing it, they canb fix it up by hand 
once it is noticed.

In principle, this is possible with uncompressed gnucash files.  But I 
don't anticipate a lot of gnucash users eager to hand-edit the XML 
files.

That's not saying it can't be done.  It can be.  But gnucash might have 
to implement its own CVS-like system to make it all work -- one that 
knows the details of gnucash syntax and ensures pieces of separate 
transactions aren't chopped up and recombined in the merge process.

Or, maybe gnucash could make sure that gnucash files follow a further 
syntax constraing -- one transaction per line, one account desription 
per line, and so forth.  That just might work with existing revisioning 
systems.

That said, if gnucash would even think of the extensive effort required, 
I would hope it would pattern it after totally distributed systems 
like monotone, which do not need a central server.  Each user has a copy 
of the entire database history.  This is a form of automatic backup as 
well as a support for change merging.

I've been looking into the problem of merging for tree-structured data.  
It isn't an easy problem, and I know of no off-the-shelf algorithms that 
handle the whole problem, preserve syntax, and are efficient.  That 
doen't mean there can't be special mechanism designed just for gnucash, 
but it would require significant errort work to achieve the kind of 
reliability we have come to expect from gnucash.

-- hendrik

> 
> /Don
> 
> >
> > He did not say that a merge is not possible. Just not always...
> >
> >> /Don
> >
> > Manfred
> >
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.