also sprach Russ Allbery <[EMAIL PROTECTED]> [2008.11.19.0122 +0100]: > You load the new upstream into the upstream branch. Now, you merge the > new upstream into the A, B, and C topic branches. In each case, upstream > used a slightly different bug fix than you had in their new release > (different wording, different comments, different whitespace, what have > you). So in each of the topic branches, you had to resolve conflicts > between the new upstream and your fix.
If upstream has fixed the problems that had you use A,B,C in the first place, why merge them back into the integration branch? After you merged upstream there, A,B,C have been obsoleted, no? Anyway, I am starting to doubt the need for a long-lived integration branch. What are the benefits of that approach, as opposed to creating a new integration branch for each Debian release? With TopGit, this would be as easy as merging upstream into master, updating all branches (which has you resolving conflicts), and then creating a new TopGit branch which depends on master (the Debianisation branch) and all the topics you want in the next release. The you build, test, upload, tag, and never touch the branch again. There is not even a point in keeping the branch around, since the tag keeps a reference to the tree you used. I use this approach for topgit itself, except that my integration branch isn't an integration branch, it's really a long-lived branch off master (the Debianisation branch), into which you keep merging master for each new release, recreate debian/patches with tg-export, and commit the new patch series. In the end, this 'build' branch just tracks the patch series on top of the master branch to use. So in the end, the dependency graph is something like (branches are capitalised, all except UPSTREAM and MASTER are TopGit-managed): UPSTREAM ---+------------- FEATURES/* (features against upstream) \ `- FIXES/* | (bug fixes against upstream) `- MASTER \ | (./debian/* files) | `- DEBIAN/* \ / (debian-specific changes) | \ \ / | `---- tg-export (quilt series generation) | | `- BUILD debian/patches/* (BUILD tracks quilt series on top of latest master) When you make a release, you build it from the BUILD branch and tag right there. When a new upstream comes around, TopGit is responsible for updating FEATURES/* and FIXES/*, you merge UPSTREAM manually into MASTER[*] and again rely on TopGit to update DEBIAN/*, you then merge MASTER into BUILD and export the patch series, commit the changes, build, tag... [*] MASTER could be a TopGit branch too off UPSTREAM, and BUILD could depend on MASTER, but then you would have to filter the branches TopGit exports, or post-hoc remove the patches from the quilt series, both of which complicate matters. With this approach, no conflict ever has to be resolved twice, though I bet it could happen if you have complex dependencies (e.g. a DEBIAN/* branch depends on a FIXES/* branch). Instead of exporting the quilt series, you could also create a new integration branch with TopGit for each release, or collapse TopGit branches into a single branch with one-commit-per-TopGit-patch. The main problem that exists still is that it is currently not possible to remove a TopGit branch when it is a dependency for another branch. This is being worked on (there is a bug report for it, "ability to remove a topgit branch", but since I am offline you need to find it yourself). The other problem, the main motivation for my current approach with the quilt series, is that TopGit cannot be used to extract patches for previous releases. Again, this is doable, but has to be implemented. See the bug report "ability to create patches from older states of topic branches" for this. -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems "writing a book is like washing an elephant: there no good place to begin or end, and it's hard to keep track of what you've already covered." -- anonymous
Description: Digital signature (see http://martin-krafft.net/gpg/)
_______________________________________________ vcs-pkg-discuss mailing list email@example.com http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss