Internally darcs always works with serialized patches. They used to be stored in lists, and could therefore be stored in either normal order or reversed order. Now there are type witnesses that signifies the order, so we can get a compilation error if we try to send a reverse list to a function that expects a normal list.
The First patch is always the patch that is applied first, and the Last patch is always the patch that is applied last. So in normal order the First patch comes first and the Last patch comes last, but in reverse order the Last patch comes first and the First patch comes last. This sounds crazy, but is important to keep in mind. The with_selected_changes_* functions partitions the list in three sections: first, middle, and last. Patches begin in the middle section, and are pushed (like on an abacus) into the first or last section on Yes and No answers. The patches always try to commute (which is not possible on an abacus), but patches that cant be commuted are pushed along into the destination section. Now, when a patch is moved into the last section of the list, very different things will happen if the patches in the list are in normal order than when in reverse order, because the will try to commute with different patches. When you Pull a series of patches you are asked about the First patch first. But when you Unpull patches you are asked about the Last patch first. When you are asked about --ask-deps patches, you are also asked about the Last patch first, but if you say Yes to a patch, you are not asked about Earlier depended upon patches, whereas in Unpull this happens if you answer No. The difference is that Unpull uses with_selected_last_changes_reversed, and --ask-deps uses with_selected_changes_reversed. In with_selected_last_changes_reversed a Yes pushes patches into the first section (because the Last patches comes first in a reverse list), and Later patches that depend on the patch are therefore forced into the first section, that is picked as the selection. In with_selected_changes_reversed a Yes pushes patches into the last section (because the First patches comes last in a reverse list), and Earlier patches that the patch depends on are therefore forced into the last section, that is picked as the selection. Pull uses with_selected_changes, where a Yes pushes patches into the first section (because the First patches comes first in a normal list), and Earlier patches that the patch depends on are therefore forced into the first section, that is picked as the selection. So there is a) the order in which to ask for patches/changes, and b) if the selection will force Earlier or Later depending patches to be selected as well. Some notes (if you will be looking at patch selection): The selection dialog in Revert feels strange to me. It has been discussed to change the way the Wait answer works. When the Wait state implicitly changes to Yes or No by dependency requirements, it lose it's implicit state. The new way would be a Maybe state, that stayed in Maybe until explicitly changed to Yes or No, and could also be explicitly set back to Maybe again. All Maybe patches would at every point in time be either Yes or No, but they would always try to gravitate back to the middle section when patches that forced them into the yes section are moved away. Then a selection could be meaningfully separated in selected patches, and forced dependency patches. This change might of course have bad implications on the speed. -- Tommy Pettersson <[EMAIL PROTECTED]> _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
