Re: How to maintain packaging files for multiple distributions in the same tree?
Manoj Srivastava <srivasta@debian.org> writes:
> On Thu, 15 Feb 2007 19:00:03 +0100, Goswin von Brederlow
> <brederlo@informatik.uni-tuebingen.de> said:
>
>> Manoj Srivastava <srivasta@debian.org> writes:
>>> On Thu, 15 Feb 2007 13:34:47 +0100, Goswin von Brederlow
>>> <brederlo@informatik.uni-tuebingen.de> said:
>>>
>>> Err, So I apply a change to say, branch--foo. The I go to
>>> branch--bar, and I say: tla replay branch--foo--revsion-x--patch-y;
>>> and the same change is applied.
>>>
>>> What if I had independently applied the same patch to both working
>>> trees? I would commit the identical change, and use tla sync-tree
>>> to let arch know the changes had been made in both branches, and
>>> any future merge should not try to redo the changes -- no matter
>>> which direction the future merge was done from.
>
>> Which means manual work which you can easily forget or even mess up.
>
> Err, if I am applying the same patch on two different
> branches (which is a pretty weird thing to do, as far as I am
> concerned), running a sync tree comes pretty naturally. Sure, I can
> also forget to breathe, and the consequences are worse :)
What I want to do is apply a patch to the common ancestry of a set of
branches but have the RCS system check that it doesn't break any
branch. Currently I have to apply the patch to one branch and then
replay, merge, pull, whatever it across all the branches that have the
same ancestry.
>>> Of course, in arch, conflicting changes in different branches is
>>> often the very reason to have the branch in the first place, so it
>>> is not really helpful to have warning emitted all over the
>>> place. I'll still learn of the changes whenever I try to merge; in
>>> which case I'll notice, and apply a sync-tree later to not redo the
>>> same change twice, and move on.
>
>> The reason I want branches is so I keep the seperate issues and
>> their patches seperate. So changes to each issue remain managable.
>
> So why are you committing the same patch to both branches? I
> have never actually had to do this, so far.
+---+
/ \
Ubuntu version +----+---+ +------+------------------
/ / / |
Debian version -+----+-----------+++------+------------------
\ \ \ |
Multiarch version +----+---+ \ |
\ \ |
+-------+----+------------------
^ initial branch ^ feature merge
^ upstream update ^ local fix for all branches
^ feature update
Say you have the above branches to maintain your package. In
particular I'm concerned with "local fix for all branches". You would
edit one branch and then want to commit the change to all
branches. Currently you have to apply the patch to each branch in cvs
or replay, merge or pull it on other RCSes.
There is no RCS that lets you edit the common source and tells you on
commit if any branch would break.
>> The problem is that when you get to 40 or 50 branches that have
>> common ancestors the required replays and merges on upstream updates
>> become complicated and time consuming. Manually pushing changes from
>> branch to branch just doesn't scale well.
>
> When I create feature branches, I generally don't go around
> pushing the same patch on to multiple branches at all. Most patches
> belong to one branch or the other.
>
> This is a hypothetical corner case that rarely happens, and
> even then, the problem only comes when merging two branches, when the
> presence of the same changes in tow different commits on either
> branch would show up. I'll just do a sync tree, and continue with the
> merge. So a patch set applied to two branches (and somehow missed
> when I create the integration branch) would be caught when I did
> anything real with the branches.
Again a "little" picture. This should be a 3 dimensional cube. Linux
versions on one axis, Lustre versions on the other and the stacked
patchs on the 3rd axis
Lustre \ Linux 2.6.12 2.6.15 2.6.19 2.6.20
1.4.6 + + + +
1.4.7 + + + +
1.4.8 + + + +
1.6.0 + + + +
Patch 1: add intents
Lustre \ Linux 2.6.12 2.6.15 2.6.19 2.6.20
1.4.6 v1 v1 v1-19 v1-19
1.4.7 v1 v1 v1-19 v1-19
1.4.8 v2 v2-15 v2-19 v2-20
1.6.0 v3 v3-15 v3-15 v3-20
Patch 2: add no-intents fixes
Lustre \ Linux 2.6.12 2.6.15 2.6.19 2.6.20
1.4.6 v1 v1-15 v1-15 v1-15
1.4.7 v1 v1-15 v1-15 v1-15
1.4.8 v2 v2-15 v2-19 v2-19
1.6.0 v3 v3-15 v3-19 v3-20
... some 20 such patches
Side note: Lustre provides the 2.6.12 patches so they are
upstream. The rest is local changes and fixes.
Each feature patch has (possible) different versions for each lustre
and linux version. Changes come from two directions and have to be
merged across that axis or across a whole plane. And the patch
versions can't be incremental. You can't have a base patch for 2.6.12
and then just add ons for 2.6.15. The 2.6.12 patch often won't apply
to 2.6.15 unaltered anymore. But they will share large amounts of
common changes.
Say I find a bug in the "add intents" patch that applies to all lustre
and linux versions. Real live example an off-by-one error in a
loop. Then I have to apply it to add-intents-v1 and replay it in v2,
v3, v1-15, v2-15, v3-15, v2-19, v3-19 and v3-20.
Say I find a bug in 2.6.19 related to "add intents" that isn't present
in 2.6.20. Then I have to branch add-intents-v1-19 as
add-intents-v1-20 (for 2.6.20) and add-intents-v3-15 as
add-intents-v3-19 and commit the change to v1-19, v2-19 and v3-19.
The problems comes when you maintain patch sets for multiple versions
of something in parallel. It becomes worse if you have an upstream
source and an upstream patch set and have to maintain multiple
versions of both in parallel. Then you commonly have to apply one
change to many branches of a patch.
MfG
Goswin
Reply to: