Re: How to maintain packaging files for multiple distributions in the same tree?
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 :)
>> 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.
> 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.
So far, and the 50 or so categories I maintain in arch, I
never had to add a patch to more than one feature branch -- and I
don't see a clear use case in which I would actually consider doing
so.
manoj
--
You will be the last person to buy a Chrysler.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: