Daniel Carrera <[email protected]> writes: > Here is another idea: > > Darcs could store two copies of each patch: One in the form that the > initial author wrote it, and one adapted to the current context. The > one that is signed is the original. This is a space-time trade-off. We > make the repository twice as large, but signing and checking patches > is O(1) because we don't need to commute anything. > > Here is an example: > > 1. Joel has repository ABCDE and creates patch F. > 2. The patch F is hashed and signed, just the way Joel wrote it. > 3. Jane has repository ABXY and pulls F from Joel. > 4. Darcs verifies F without having to commute anything. > 5. Darcs turns F into F' to apply it to Jane's context. > 6. Darcs keeps both F and F' in the repository. > > > Later on, if Mike pulls that patch from Jane, he'll get F with its > signature. Notice that in general this system does not require more > bandwidth or more time to merge. In general, there is no reason to > think that F will be harder to apply than F'. > Since Mike is pulling from Jane, we can assume that Joel is off-line forever, and that Mike has a repository like ABXYMN [and wants to ABXYMNF'']. Step 5 is now impossible for Mike. He has no access to CDE (since Joel died in a mysterious car-crash after Jane fixed his brakes), which he needs to check that F and F' are related, and that the package he got from Jane is not: -F -Signature of F -G, an evil patch pretending to be F'.
So this system is incompatible with the distributed nature of darcs. Florent _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
