Twas brillig at 23:07:49 06.03.2009 UTC+06 when did 
gyre and gimble:

** Scenario 3. "Full-blown development".

This is scenario for the packages which need the lot of work downstream
(e.g. kernel).


Tree layout:
 foo/        (in upstream, patched in topic-*, master)
 .gear/rules (in master)
 foos.pec    (in master)

1. Importing the source to the upstream branch

As in previous scenarios.

2. Working on package.

All the work is done in topic branches, each is dedicated for some topic:

$ git checkout topic-A
$ vim ... # hack-hack-hack
$ git commit
$ git checkout topic-B

As patches may overlap, some conflict resolution need to be
involved. The naive approach would be using the following branching

* upstream
\--> topic-A
\--> topic-B
\--> master

And then generating patch-per-topic by using .gear/rules. This will not
work, as the generated patches will conflict.

Instead, the following scheme is used:

* upstream
\-> topic-A
    \-> topic-B
        \-> master

And gear-merge(1) utility merges the branches as described in
.gear/merge file:

  merge: upstream topic-A
  merge: topic-A topic-B
  merge: topic-B master

After using this utility (and resolving all conflicts occured), master
branch gets a cumulative change.

3. .gear/rules

The .gear/rules file will be exactly the same as for previous scenario,
so the gear-update-tag(1) is also reuired:

  tar: v...@version@:foo
  diff: diff: v...@version@:foo foo

4. Build

$ gear-rpm/gear-hsh (as in previous scenario).

5. Rebasing to new upstream version

$ ... # obtain the new upstream code in upstream branch
$ gear-merge
... Fix conflicts, update changelog, remove unnecessary patches etc...
$ gear-commit

Due to gear-merge, it's only necessary to fix the conflicts once.

6. New package revision

$ vim ... # hack-hack, commit
$ gear-merge


Attachment: pgp8Z9Gag2cLs.pgp
Description: PGP signature

vcs-pkg-discuss mailing list

Reply via email to