[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to maintain packaging files for multiple distributions in the same tree?

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.

> 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.

        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.

        This does require a certain discipline of single change per
 commit, but that is good practice anyway.

> The same would hold for a patch set where each patch is stacked on
> top of all the others. If you edit the source at patchlevel 3 and
> then commit the changes it would automatically check that
> patchlevels 4, 5, 6, ... still apply without conflict.

        I don't do stacked patches, (and this is one of the reasons);
 I prefer pure feature branches and an integration branch; any
 conflict would show up at merge into the integration branch; and can
 be handled then.

        The advantage is that the patchset for each feature gets fixed
 automatically once you get your integration branch into good shape --
 so I never really have to worry about gazillions of patches, just
 make sure the integration branch compiles correctly; adjusting each
 feature branch as needed (which, despite what it may sound like, is
 really a simple operation in practice).

Proclaim liberty throughout the land until all the inhabitants
thereof. Leviticus 25:10
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: