On 06/24/2011 02:17 AM, James Westby wrote:
> Review: Approve
> Hi,
>
> This looks fine.
Appreciated, as always :)
>
> What's your plan for representing the multiple upstream tarballs in
> the tree and revision history?
Basically importing each upstream component tarball as a separate
revision with its own history and tagging them appropriately:
* "upstream-1.0" for bar_1.0.orig.tar.bz2
* "upstream-1.0/bla" for bar_1.0.orig-bla.tar.bz2
... and then having the package branch take these revisions as parents,
making the components look like by-value nested trees. If an upstream
component tarball hasn't changed between upstream releases we just retag
it.
Does that sounds reasonable?
I'm also wondering if we should add a "deb-components" revision property
so that we don't accidentally forget to export component tarballs if the
appropriate tags are missing. What do you think?
On 06/24/2011 02:17 AM, James Westby wrote:
> Review: Approve
> Hi,
>
> This looks fine.
Appreciated, as always :)
>
> What's your plan for representing the multiple upstream tarballs in
> the tree and revision history?
Basically importing each upstream component tarball as a separate
revision with its own history and tagging them appropriately:
* "upstream-1.0" for bar_1.0. orig.tar. bz2 orig-bla. tar.bz2
* "upstream-1.0/bla" for bar_1.0.
... and then having the package branch take these revisions as parents,
making the components look like by-value nested trees. If an upstream
component tarball hasn't changed between upstream releases we just retag
it.
Does that sounds reasonable?
I'm also wondering if we should add a "deb-components" revision property
so that we don't accidentally forget to export component tarballs if the
appropriate tags are missing. What do you think?
Cheers,
Jelmer