Branching from an import, but briefly using an svn branch
Colin Watson
cjwatson at ubuntu.com
Sun Jul 9 22:41:43 BST 2006
On Fri, Jul 07, 2006 at 11:29:08PM +0200, David Allouche wrote:
> Colin Watson wrote:
> > Summary: I'm in the process of creating a bzr branch of a vcs-import;
> > the branch represents the history of an Ubuntu package, based on the
> > corresponding Debian package (which in this case equals upstream). The
> > code in Debian is stored in an svn repository. For the most part, the
> > import comes from the trunk; however, there was a brief period in the
> > Ubuntu package's history where it was based on an svn branch. I
> > understand that imports of svn branches are not supported and that this
> > is unlikely to change in the near future. What is my best course of
> > action?
>
> If I understand correctly, the topology of the problem looks like:
>
> SVN trunk: T1* ---> T2 -----------> T4*
> \
> SVN branch: `--> B3*
>
> Where stars denote released versions.
Yes, that's correct.
> > What is the best way for me to represent this history in bzr? I can see
> > two reasonable courses of action:
>
> What do you want to achieve by recording past ubuntu packages in bzr
> branches?
>
> Installer code does not seem much of a candidate for security fixes, I
> do not think it needs different active versions for the various
> maintained distro releases. So there is no need to merge between past
> and future packages.
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.
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.
> 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.)
> > * 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 ...
> > It also requires me to figure out how to run it
> > in a way that produces "safe" imports (i.e. with the correct ids
> > etc.), and I might need help with that. However, it produces the
> > highest quality of import.
>
> 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'm also interested in solving the problem while it is still essentially
academic, before it becomes an urgent practical issue. It is likely that
at some point in the future I will once more have to produce Ubuntu
packages based upon an SVN branch of some installer package, and at that
point it will be necessary for me to merge from upstream to my Ubuntu
branch.
[snip technical details; thanks, I think I understand that]
> Though I would welcome your help in dealing with this issue, as it
> applies to the "renamed branch case", and supporting it is in scope for
> the current level of Subversion support Launchpad wants to provide.
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.
Thanks for your detailed reply,
--
Colin Watson [cjwatson at ubuntu.com]
More information about the launchpad-users
mailing list