syncing two pcs

[Donald Allen]

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.

/Don

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