* Manoj Srivastava: > But there is no such linearization, not in the way that quilt et > al do it. The state of such integration is not maintained in the > feature branches; it is in the history of the integration branch. As > each feature branch was created or developed, if there were any > conflicts, these conflicts were resolved in the integration branch. And > the integration branch does not keep track of what changes come from > which branch -- that is not its job. And it does not keep the > integration patches up to date either -- that again is not its > job. Details below.
There are some systems that automatically push changes on a branch to all branches that branched from it (Clearcase is in that category, IIRC, and Aegis does something similar). My experience with Aegis is that this is usually *not* what you want, and the prevalent DVCS model uniformly rejects this idea. However, this would help to get rid of the integration branch. Changes to lower branches would bubble up, if necessary with manual help, and a separate integration branch would not be necessary. I'm not sure if this is actually workable (probably not with the branching model currently in fashion), but it might be. Anyway, this gets me back to my original question: Is there tools support for dealing with patch series (quilt or dpatch) which lets me bubble up patches (including new upstream versions, at least conceptually) and sink them down the queue? With three-way merging, so that it's comparable to typical in-VCS operation? Has anybody written the converse to git-quiltimport (which should go to great lengths not to create any gratuitous changes), and a port of that script to dpatch? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
