[darcs-users] rebase feedback and amend-record flexibility

[Michael Hendricks]

On Mon, Apr 2, 2012 at 6:42 PM, Ben Franksen <benjamin.franksen at bessy.de>wrote:

> > If I want to change the meta data for patch P, three are three possible
> > scenarios: no patches depend on P, a patch Q implicitly depends on P, a
> > patch Q explicitly depends on P (via darcs record --ask-deps).  The first
> > scenario is trivial and amend-record handles it well today.  The second
> > doesn't mutate Q, so Darcs should handle allow it but doesn't.
>
> But it does mutate Q.
>
> Suppose I have a patch named "fuzzled the wombaz", publish it, and then in
> my local copy I rename it to "foozled the wombaz". Then a darcs pull would
> pull in the original "fuzzled the wombaz" and then I had /two/ patches that
> did the same thing with slightly different names (and/or dates, authors,
> hash keys, etc).
>
> I want to avoid such a situation.


Me too. That's one reason I liked your proposal to warn about amending an
already published patch.


> Ok, so you are aware of how things are, but you think meta data should not
> be part of the patch identity?
>
> But then how does the system keep track of /which/ meta data is the right
> one?


For unpublished patches, there should be no confusion.  For published
patches, I assume darcs would behave like it does now: refuse to push a
patch if the receiving repository already has one with that identity.

In a way, yes. However, this is an implementation point of view, as opposed
> to the user interface. From the UI perspective, commutation is not
> something
> that has to be done, it is a fact. Change A commutes with change B, period.
> For me this means that there is no ordering relation between the two, and
> the way darcs lists them when I do 'darcs changes' is purely incidental. I
> think of a repository as a /set/ of changes, and I (mostly) regard two
> repositories that contain the same set of changes as equal.
>

I agree completely.  I think my proposal would make darcs appear even more
like a set of changes.  Consider the following two scenarios where patches
B and C depend on A but not on each other:

  record A
  amend B into A
  record C

  record A
  record C
  amend B into A

With today's amend-record, the first succeeds and the second fails because
darcs is paying too much attention to the order in which I record patches.
 Under my proposal, both would succeed.

> For example, imagine having patches A and B where B depends on A.  I want
> > to amend changes C into A.  C does not depend on B.  Today's darcs fails
> > this case because A can't commute to the front.  However, we could
> commute
> > C backwards to get ACB, then combine into A'B
>
> (I think you meant to say A'C)
>
> Hm. But in this case the following should work
>
> * temporarily obliterate B (keeping a copy in a clone)
> * amend-record, combining A and C into A'C
> * pull B from the clone...oops (conflict)
>
> We cannot pull B with out pulling A. Because B depends on A. And A is no
> longer available locally, it has been changed into A'B. So B tries to pull
> A
> along, which most likely will lead to a conflict and to considerable
> confusion too, because A'B might have the same name as A.


If B is moved elsewhere, you're right, it can't work.  B must remain in the
repository so darcs can properly adjust it when commuting C past B.

Thanks for the thoughtful scenarios.  It's helped me solidify some of these
ideas in my mind.

-- 
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20120403/af5f6524/attachment.html>