[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal
Date: Wed, 27 Oct 2004 20:18:52 -0400
User-agent: Mozilla Thunderbird 0.8 (X11/20040926)

One of the features of Arch I really like is the history-sensitive merging. This process breaks history-sensitive merge commands.

I happen to know that address@hidden/tla--devo--1.3--patch-7 is a merge of changes I made in my tlasrc--devel--0.2 tree. But since the only patchlog is the one for address@hidden/tla--devo--1.3, I cannot use replay --skip-present address@hidden/tla--devo--1.3 to apply the latest changes to my tree. Ironically, very few people aside from me will have this problem. James will, since he merged me.

But this process essentially penalizes people for contributing code.

These problems do not necessarily go away if we change to a one-version-per-merge model. It's quite likely that my submissions will not be originated in the version that I submit for merging.

Many of the patches I submitted for 1.2.2 needed work before they could merge cleanly. So five of my submissions were from tla--submit--1.2.2. I think we can pretend that it was a submission version as described in the plan. But it's quite reasonable that my tlasrc--devel--0.2 tree would have no patchlogs for tlasrc--devel--0.2. The patches were either developed there, or entered it by a different route.

Your =merged idea provides a way to determine what the direct merges are-- kinda-sorta. It's not guaranteed to be right, because it's not guaranteed that all of the revisions in the version were, in fact, merged, and that no revisions have been added since the version was merged. But I'm arguing that the indirect merges are important also, and so =merged is not an adequate solution.

Let's end with a threat: if you go ahead with =merged, I will do my level best to support it in Fai. For cases where the merged version has patchlogs in the tree, I can implement a "replay --skip-present" workalike that will use the changeset contents to determine whether a patch should be applied. That will make Fai a significantly less broken tool for developing tla than tla itself. You don't really want that, do you? :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]