Changes between Version 3 and Version 4 of TwoWaySync


Ignore:
Timestamp:
12/13/05 17:40:19 (7 years ago)
Author:
anonymous
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • TwoWaySync

    v3 v4  
    1212witness) 
    1313 
    14 zooko's recipe 
     14Zooko's recipe 
     15 
    1516============== 
    1617 
    17 Let there be two tailor directories, once which ports patches from svn 
    18 to darcs (called `"SD"` from here on) and one which ports patches from 
    19 darcs to svn (called `"DS"` from here on). Each of these tailor 
    20 directories contains an svn working dir subdirectory (called `"SDs"` or 
    21 `"DSs"`) and a darcs repo subdirectory (called `"SDd"` or `"DSd"`). 
     18Let there be two tailor directories, once which translates patches from svn to darcs (called `"SD"` from here on) and one which translates patches from darcs to svn (called `"DS"` from here on). Each of these tailor directories contains an svn working dir subdirectory (called `"SDs"` or `"DSs"`) and a darcs repo subdirectory (called `"SDd"` or `"DSd"`). 
    2219 
    23 In addition there is (of course) the SVN repo "SO" and an "official" 
    24 darcs repo "DO". 
     20In addition there is (of course) the SVN repo `"SO"` and an official darcs repo `"DO"`. 
    2521 
    26 Let `"the internally consistent condition"` be such that the contents of 
    27 all four of the subdirectories SDs, SDd, DSs, and DSd are up-to-date 
    28 with each other, and furthermore that SDs and DSs are each a subset of 
    29 SO (i.e., svn diff would show no changes) and SDd and DSd are each a 
    30 subset of DO (i.e. darcs push DO would have no effect). 
    3122 
    32 `Subroutine C`_ will return to the internally consistent state when it 
    33 completes, if possible. If it is not possible to return to the 
    34 internally consistent state then there is a conflict which has to be 
    35 resolved by the user. 
     23.. _subroutine CLEANUP: 
    3624 
    37 Let `"the up-to-date condition"` be such that the contents of all six of 
    38 SDs, SDd, DSs, DSd, SO, and DO are up-to-date with each other. The 
    39 up-to-date condition implies the internally-consistent condition. The 
    40 complete Algorithm -- Algorithm D will result in the up-to-date state 
    41 unless there is a conflict or unless new patches are added to SO or to 
    42 DO after the algorithm has checked for new patches and before it 
    43 terminates. 
     25Subroutine C: clean up any intermediate state 
     26-------------------------------------------------------- 
    4427 
    45 I'll first show three subroutines and then show the complete algorithm. 
     28Make sure that any intermediate state left behind from Subroutines A or B completing, raising MergeConflict, or crashing (i.e. being killed in mid-step) gets cleaned up and that we return to the Internally Consistent State if possible, or else raise an error if impossible.  CLEANUP has to be run at the beginning of every run of the two-way-sync algorithm, since we never know if the previous run crashed and left things in an inconsistent state. 
     29 
     301. For each patch in SDd which has the special line as the last line of the log entry, run {{{darcs obliterate}}} to obliterate that patch from SDd. 
     31 
     322. {{{darcs pull -a $DSd}}} in SDd to pull all darcs patches from DSd into SDd. 
     33 
     343. {{{darcs push -a DO}}} in SDd.  If the push fails (which will happen if it would cause a conflict in DO) then raise MergeConflict. 
    4635 
    4736.. _subroutine a: 
    … …  
    5039-------------------------------------------------------- 
    5140 
    52 1. Use tailor in the SD directory to translate the next patch from SVN 
    53    to darcs. This will update SDs to that revision and add a new patch 
    54    into SDd. Let REVNUMBER be the svn revision number of the original 
    55    svn patch and let HASH be the darcs identifier of the newly created 
    56    darcs patch. 
     411. Run {{{CLEANUP()}}} 
    5742 
    58 2. Use darcs push --match='hash $HASH' to push the resulting darcs 
    59    patch from the SDd to DO (where HASH is equal to the hash of the 
    60    patch which was just created). If the push fails for the reason 
    61    that pushing would cause a conflict in DO then this algorithm must 
    62    stop and notify the user of a conflict condition. 
    63  
    64 3. Run svn up -r$REVNUMBER in DSs (note: not SDs), with REVNUMBER 
    65    equal to the revision number of the patch that was translated from 
    66    SVN world in step A1. 
    67  
    68 4. Run ``darcs pull --match='hash $HASH'`` in DSd (note: not SDd), with 
    69    HASH equal to the hash of the patch which was created in darcs 
    70    world in step A1. 
    71  
    72 Observe that if the internally-consistent condition held before 
    73 `Subroutine A`_, and there was no conflict, then the 
    74 internally-consistent condition must hold after `Subroutine A`_. 
     432. Use tailor in the SD directory to translate the next patch from SVN to darcs. This will update SDs to that revision and add a new patch into SDd.  If there are no more untranslated svn patches in SO then raise StopIteration. 
    7544 
    7645.. _subroutine b: 
    … …  
    7948-------------------------------------------------------- 
    8049 
    81 1. Use tailor in the DS directory to translate the next patch from 
    82    darcs to SVN. This will pull the next patch from DO into DSd and 
    83    create a new revision in DSs and attempt to commit it to SO. Let 
    84    REVNUMBER be the SVN revision number of this patch. 
     501. Run {{{CLEANUP()}}} 
    8551 
    86 2. If the attempt to commit the new patch to SO fails due to merge 
    87    conflict then this algorithm must stop and notify the user of a 
    88    conflict condition. 
     522. Use tailor in the DS directory to translate the next patch from darcs to SVN. This will pull the next patch from DO into DSd and create a new revision in DSs and attempt to commit it to SO.  The newly created SVN revision will have a special line appended to its log entry saying "This patch originally recorded in darcs and translated into SVN by TAILOR brand revision control translator.".  If there are no more untranslated patches in DO then raise StopIteration.  If the attempt to commit the new patch to SO fails (which it will if there is a merge conflict) then raise MergeConflict. 
    8953 
    90 3. Verify that there were no changes in SO between the previous 
    91    REVNUMBER from the last time step B4 was run (if any) and the 
    92    current REVNUMBER. If there were changes in SVN between those two 
    93    revisions then flag a conflict and stop. 
     54.. _algorithm c: 
    9455 
    95 4. Run ``svn up -r$REVNUMBER`` in SDs (note: not DSs). 
     56Algorithm C: complete sync 
     57-------------------------- 
    9658 
    97 5. Run ``darcs pull --match='hash $HASH'`` in SDd (note: not DSd), with 
    98    HASH equal to the hash of the patch that was translated from darcs 
    99    world in step b1. 
     59Run Subroutines A and B until they both raise StopIteration.  I haven't figured out in which order it is best to run them.  My current intuition is that it is best to run Subroutine A until it raises StopIteration, then run Subroutine B one time, then run Subroutine A against until it raises StopIteration again, then run Subroutine B again one time, etc.  My main motivation is that this means any potential merge conflicts happen in darcsworld rather than in svnworld, which should reduce the number of merge conflicts and make the inevitable merge conflicts easier to clean up.  But see "Incomplete Design" below. 
    10060 
    101 Observe that the starting from the internally-consistent condition is 
    102 necessary but not sufficient for Subroutine B to result in the 
    103 internally-consistent condition. In addition to the 
    104 internally-consistent condition, another condition is required, namely 
    105 that SDs is required to have been up-to-date with SO. If SDs was not 
    106 up-to-date with SO before Subroutine B, then step B4 will, in addition 
    107 to adding the new patch into SDs also add other patches into SDs which 
    108 are not also in SDd, violating the internally-consistent 
    109 condition. This is why step B3 has to be inserted in Subroutine B. 
     61Incomplete Design 
     62----------------- 
    11063 
    111 That motivates us to invent this subroutine: 
    112  
    113 .. _subroutine c: 
    114  
    115 Subroutine C: translate all patches from SVN to darcs and then translate the next patch from darcs to SVN 
    116 --------------------------------------------------------------------------------------------------------- 
    117  
    118 1. Iterate `Subroutine A`_ until there are no more patches in SO that are 
    119    not already in SDs, i.e. that SDs is up-to-date with SO. 
    120  
    121 2. Run `Subroutine B`_. 
    122  
    123 .. algorithm d: 
    124  
    125 Algorithm D: translate all patches between worlds 
    126 ------------------------------------------------- 
    127  
    128 1. Iterate `Subroutine C`_ until there are no more patches in DO that are 
    129    not already in DSd, i.e. that DSd is up-to-date with DO. 
    130  
    131 Now it is safe to invoke Algorithm D whenever you want to synchronize 
    132 the two worlds. One of three things will happen: 
    133  
    134 1. the worlds will be synchronized 
    135  
    136 2. it will turn out that there is a merge conflict, Algorithm D will 
    137    stop at that point (either Step A2 or else step B2) and notify the 
    138    user. 
    139  
    140 3. it will turn out that another patch was committed to SO between 
    141    Step C1 and Step C2. Algorithm D will stop at that point and notify 
    142    the user. 
     64What does the user do in response to MergeConflict in order to get back into the Internally Consistent State? 
    14365 
    14466Limitations