On Wed, May 30, 2007 at 03:49:35PM -0700, Jason Dagit wrote:
>
> 2) An activation patch should never modify other patches. An
> activation patch is not designed to modify the repository state
> directly. That means, using the above notation for context, that an
> activation patch has this form:
> o (_A_) o
I'm a little lost by what your notation means here.
The context (o) is (in my head, at least) a set of patches. If (_A_) is
a patch then it must have a name, or we won't know things like whether
we already have it or not; suppose its name is nA. Then we must have
o (_A_) a
where a = o union { nA }
Do you mean that the pristine tree is identical before and after (_A_)?
> 2) An activation patch is its own inverse. Since the activation
> patch does not modify the repository state, it should be clear that
> the patch is its own inverse.
By similar logic, (_B_) is another inverse of (_A_). Surely that's not
true? The inverse of (_A_) must be determined by some semantics that
haven't been discussed yet, no?
> The first property we implemented was to handle the dependency between
> the activation patch and the activated patch. It looks like this:
> activation_commute_patch :: (Patch, Patch) -> Perhaps (Patch, Patch)
> activation_commute_patch (p1, Activation p2 [])
> | eq_patches p1 p2 = Failed
It would be nice if we had a name to carry around, rather than having to
carry around the actual patch. I think doing so would allow you to
eliminate the context that you carry around, which would simplify
things.
Is there something that means we can't do this?
(We can make names using a scheme like:
The n'th primpatch in the named patch N has name N.n)
Thanks
Ian
_______________________________________________
darcs-devel mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-devel
