Thank you very much for the questions. Hopefully David will comment
about the name patches (below) or on any mistakes I've made.
On 5/30/07, Ian Lynagh <[EMAIL PROTECTED]> wrote:
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_)?
Basically, yes the pristine cache is not modified by (_A_). After
some consideration I think this gets a bit tricky because the
existence of an activation patch could very well change the state of
the pristine cache. That's part of why we're introducing them. They
are there to explicitly activate a patch, and that patch may, in
general, change the state of the pristine cache.
Perhaps it's better if I referred to o above as an 'application
context'. I agree that a context should be a set of patches. What
I'm unclear about is how to describe what I mean by those little
letters. They represent the context in so far as to tell you when
it's acceptable to put the patches in sequence, but then the
activation patches don't get included in that set of patches. For
example, I want the following to be true:
o A a B b <--> o B' t1 A' b
That is, I have patches A and B which commute. Now when I introduce
an activation patch on A, I need to create it adjacent to A for the
commutation rules to be expressible. So, I insert the activation
patch between A and B, and similarly I can do this for an activation
on B:
o A a (o _A_ a) a B b (a _B_ b) b <-->
o A a B b (t1 _A'_ b) b (a _B_ b) b <-->
o A B b (a _B_ b) b (t1 _A'_ b) b
What I'm trying to demonstrate is that moving the activation patches
around should not affect the other patches. The consequence of this,
is that the 'application context' I'm writing between the patches
should not be modified (except in the case of the activation patch,
where it must be modified or else it would disturb the surrounding
sequence of patches).
> 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?
Good point. I'm looking and looking for something else we state or
discussed that would force the activation patch to be the unique
inverse of itself. I cannot think of anything here. David can you
think of something?
I would argue that we want an inverse, and we know that the activation
patch does not change other patches during commutation (and has no
direct affect on the pristine cache), so the simplest inverse we can
choose is itself. So that's exactly what we do. We take the simplest
approach.
> 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.
Would activations not be a patch if done that way? I believe we want
activations to propagate and move around like all the other patches so
it seems important to implement them as patches.
Supposing we implemented an activation patch as just the name of the
patch which it activates? I'm at a lose to construct a counter
example or counter argument to doing this. I'll think about it more.
I don't see any problem it creates with cherry picking the activation
patch, but maybe my commutation and general darcs knowledge is still
too weak.
Perhaps when we add some of the other planned modifications into the
mix having the patch and the context become better than just the name.
Is there something that means we can't do this?
I think maybe, but if I'm right then it's not something I've mentioned
to you yet :) David and I would like to introduce anonymous patches
and name patches to help reduce the ways in which conflicts can occur
and also to (hopefully) increase the ability of composite patches to
commute freely.
I think the rough idea is that all patches will no longer have a name
and will hence be anonymous. Names are useful and good, so we'll then
introduce a name patch. A patch which holds just its name but is
otherwise anonymous like all other patches. I'm not solid on the
details yet (part of the reason I didn't bring it up). For example,
I'm not sure yet how name patches will associate with anonymous
patches to provide them with names. Although, I believe they will be
quite a bit simpler than activation patches. They will be almost
completely trivial I think.
(We can make names using a scheme like:
The n'th primpatch in the named patch N has name N.n)
Sort of Name.index?
Thanks,
Jason
_______________________________________________
darcs-devel mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-devel
