On Mon, Apr 2, 2012 at 6:42 PM, Ben Franksen <[email protected]>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
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
