Re: How to maintain packaging files for multiple distributions in the same tree?
Manoj Srivastava <srivasta@debian.org> writes:
> On Thu, 15 Feb 2007 13:34:47 +0100, Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> said:
>
>> Manoj Srivastava <srivasta@debian.org> writes:
>>> On Thu, 01 Feb 2007 14:47:59 +0100, Goswin von Brederlow
>>> <brederlo@informatik.uni-tuebingen.de> said:
>>>> If you had true parallel revisions then there should be a way to
>>>> edit both "branches" at the same time and check in changes to both
>>>> at the same time.
>>>
>>> This is trivial using arch and bazaar-ng, and probably any other
>>> modern distributed version control system. I can make
>>> non-conflicting changes to multiple branches (think typo fixes),
>>> and check them all in all at once.
>>>
>>> manoj
>
>> That is not what I ment. You are taling about different changes for
>> each branch while I mean identical changes to the common parts of
>> both (all) branches.
>
> 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.
>> What I have in mind is that you work on your local copy of the
>> source and then "foo commit" your changes. That then checks that the
>> changes apply to both branches and warns you about possible
>> conflicts, for example "Change of src/foo.c creates conflict for
>> branch feature2".
>
> Err, that already happens, even with CVS. You edit your local
> copy, checking in to CVS warns you about not up-to-datedness; cvs
> update warns you of conflict.
Not between branches.
> 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.
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.
MfG
Goswin
Reply to: