recreating historic packages

[Manoj Srivastava]

On Tue, Sep 30 2008, martin f krafft wrote:

> also sprach Manoj Srivastava <srivasta at acm.org> [2008.09.30.2131 +0200]:
>>         At this point, pre-topgit, that is what my tags do:
>>  I tag the ./debian/ branch and the integration branch. Checking out the
>>  tag on the integration branch, and installing the submodules, are all
>>  you need to do. The single tag checkout reproduces exactly the state of
>>  the tree that was used to build the package.
>
> Not all patches are suitable to be stored as submodules. So you have
> to merge anyway. topgit can automate the merging for you, it can
> manage your integration branch.

        Since I only store ./debian into a submodule, and updatream does
 not have ./debian, nothing ever needs merging.

> The only difference between your workflow and the one I use for
> topgit right now is that I take the extra step to export the quilt
> series from the integration branch (which I call stage-x.y-z and
> it's temporary as I see no need to keep it around (yet)) and store
> it in the build branch, which I then tag.

        Hmm. In my case, the integration and build branches are the same
 (master, for me). It would be slightly awkward to put stuff into a
 ./debian/patches for me, since ./debian is a submodule, and thus a
 different project. What you put into your build (master) branch, I put
 into a submodule. I find it conceptually cleaner; ./debian has little
 to do with upstream, but is close to all other ./debian directories in
 my other packages.

        In my case, the integration/build branch has all the changes + a
 submodule; your build branch (called master) is the same as upstream,
 with the exception of also having the ./debian directory and has
 ./debian/patches.

        Your throw away integration of staging branch is recreated by
 quilt during build.

> You could just create a tg branch depending on master (which depends
> on upstream) and all topic branches (which each depend on master or
> upstream, depending on whether they are debian-specific or
> for-upstream) and then tg-update on that branch would "integrate"
> all your features and you'd have an up-to-date integration branch to
> tag.

        But this integration branch is not the branch that goes in the
 source package, right?  Since the source package needs to be identical
 to upstream code, and on top of which the quilt series is to be
 applied.

> I could see using a persistent stage branch for this from which
> I export the quilt series. That would unify the two workflows up
> until the last step.

        Yeah. Hmm. I need to think some more about this.

        manoj
-- 
"I just couldn't convince Texans that Dukakis was Greek for Bubba."
Lloyd Benson
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C