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

[James Blackwell]

Hi guys,

I keep thinking about the part of Tom's release proposal as it relates to
patch-log pruning.

I can't quite get my mind around the log pruning. As I understand things,
this will make foreign trees difficult, if not impossible to manage. The
problem goes along these lines.

First, assume trees A, B and C. B regularly merges from A, but in the
process prunes the patch-logs.  C replays/updates/star-merges from B.

Things still look reasonably sane, right?

But now imagine what happens if C attempts to replay from A after
replaying from B. C is going to end up in a pretty big mess, because
without those patchlogs, C doesn't realize that the patches have already
been applied, tries to apply the same patches twice, and then *boom*.

What's this mean? This means that C can replay from either B or A, _but
not both_. To do so would end up with conflicts up the yingyang.

Though I think the intent is just to clean out old cruft (too many patch
logs do slow down the tree a bit), it seems to me that it also
unintentionally results in one of two possibilities: Either power is
centralized in B, or B and C are precluded from working together if both
happen to take revisions from external sources.

Hopefully I'm missing something obvious, because if I'm not, then this
would be a terrible direction in which to take arch, because it would
prevent closely related branches from maintaining a close relationship...
i.e. it would encourage arch to diverge, rather than converge.


-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400