syncing two pcs

[Manfred Usselmann]

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.

He did not say that a merge is not possible. Just not always...
 
> /Don

Manfred