Branching from an import, but briefly using an svn branch

[David Allouche]

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.

> 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.

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.

>   * 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.

> This takes advantage of the fact that I happen to
>     have access to that version of cscvs (and indeed have contributed
>     improvements to it in the past), and so I suppose it might
>     contravene policy.

There is no policy that prevents that. The Launchpad version of cscvs
must not be distributed (at least until we have completed bzr support
and removed Arch support), but the data it produces can be distributed.

> 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?

cscvs records the SVN revision number used to produce each imported
revision (in bzr, it's in Revision.properties['cscvs-id']). In
subversion, the complete (recursive) log of a branch starts after the
revision of the branch point. In the above diagram, all revisions in B
are greater than the revision of T2.

To extract the branch point from the bzr import of T you need to:

* examine the svn log of B to find the revision of T it was copied from

* bzr branch the import of B at the revision with the corresponding
cscvs-id revision property

Then you need to (somehow) create a bzr revision with the appropriate
contents and cscvs-id for the initial svn revision on B. If the
branching was done by a simple "svn cp" with no additional change, that
revision would make no textual change.

If you are lucky, creating that revision could be done by running cscvs
 to import the first revision from B. You want to do a cscvs run that
imports a single revision to exercise the cross-check logic ensuring
that the import is consistent with the svn checkout at hand.

If you are unlucky, you may need to add a flag to apply Source objects
instead of Change objects, and also cope with files that may not have
been copied across to the new branch.

Once you have created the import of the first revision on the branch,
cscvs should be able to proceed normally.

This technique also applies to the "renamed branch" case since, in
Subversion, a renaming is recorded as copy with a simultaneous deletion
of the old name.

>   * Manually import each successive Debian package release along the
>     branch from 1.35 to 1.35.5 in the same way that I import old Ubuntu
>     packages (i.e. by unpacking the package, copying in the .bzr
>     directory from the previous one, dealing with any file adds or
>     renames, and running 'bzr commit'). This would work now without any
>     particular controversy; the Debian package releases in question are
>     all available from snapshot.debian.net. However, if the upstream
>     branch were ever imported in future, my branch would not be
>     compatible with it. This isn't a particularly big deal in this
>     particular case, but it might be an issue in some other similar case
>     in future.

You probably want choose that option for now.

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.

-- 
                                                            -- ddaa