Branching from an import, but briefly using an svn branch

[David Allouche]

Colin Watson wrote:
> As a point of information, there *have* been installer security issues
> in the past, and I am aware of at least one (relatively minor) issue to
> address right now. Furthermore, in the case of Dapper we intend to
> produce point releases that include installer changes to fix various
> high-visibility bugs, and it's still possible that we will make a point
> release of Breezy. So, for certain installer packages, I do in fact
> expect to have to merge between past and future packages.

Thank you, I was not aware of that.

> That said, the bulk of my motivation for importing the full history is
> simply having the history of the package conveniently to hand for
> annotate etc. It is very common for me to be asked about some detail of
> the installer's behaviour in a past release, and it's inconvenient to
> depend on the huge stash of source packages I keep on my laptop's hard
> disk for this sort of archaeological investigation.

So you wish to use "annotate etc." on branches that represent each
source package release. That makes sense.

>> Representing the history in the most faithful way possible requires a
>> significant amount of fiddling, mainly to find the revisions on the vcs
>> import branch matching the orig of each package.
> 
> (I don't understand why this is more the case for a branch import than a
> trunk import, if the necessary branch is explicitly requested by
> somebody who cares about that package. I understand the problem of
> matching up .orig.tar.gz files when they might not correspond exactly to
> something in revision control, but the upstream installer release
> practices are pretty good so it's not a problem that bites me in the
> installer enough for me to care about.)

It's not more the case for a branch import, and I was not thinking of
the case where there is no revision in vcs history that matches a source
package.

I was just thinking of the trouble of finding the bzr revision matching
the svn revision a package was made from. But I can believe that in some
cases the history is well understood enough for this not to be difficult.

>>>   * Attempt to run Launchpad's version of cscvs manually on the svn
>>>     branch, and merge the resulting bzr branch into my Ubuntu branch of
>>>     base-installer.
>> I take it you mean: "use cscvs to import the etch-beta1 branch based on
>> the trunk import".
>>
>> I would be interested in knowing if and how you manage to get that working.
> 
> I'm afraid I eventually opted for manually importing the five successive
> Debian package releases, in the interest of expediency. Edgy's upstream
> version freeze is approaching rapidly ...

Fair enough. It was a tall order I gave you :)

>> I take it by "safe" you mean producing an import of the etch-beta1
>> branch which is properly rooted on the trunk import branch, such as
>> merging it with trunk would produce meaningful results.
>>
>> What would you gain by doing this for past package releases?
> 
> I'm a picky bastard. :-)

I can certainly relate to that :)

> In such copious free time as I have, I'll see if I can get a cscvs run
> working properly for the renamed branch case, which as you note is
> largely equivalent to the case of 'svn cp' without other simultaneous
> changes; as I noted, upstream installer release practices are generally
> sensible, which includes avoiding such simultaneous changes.

In this particular simple case, it might go fairly smoothly.

By the way, note that the cscvs in rocketfuel currently has the ability
to import natively to bzr. I am still in the process of converting the
test suite, but it appears to be good so far.
-- 
                                                            -- ddaa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/launchpad-users/attachments/20060711/dbe1ec26/signature.pgp