migrating from CVS

[David Allouche]

On Mon, 2006-03-06 at 12:21 -0800, Jos Backus wrote:
> On Mon, Mar 06, 2006 at 01:51:30AM +0100, David Allouche wrote:
> > Launchpad does support partial modules (foo apps/foo) but does not
> > currently support import of non-MAIN CVS branches. If all goes well, the
> > existing imports (currently in Arch) will be published as bzr branches
> > this week.
> 
> Sounds promising. What do you mean by `the existing imports'? Are there any
> plans for converting non-MAIN CVS branches?

The "existing imports" are a handful hundreds of VCS (SVN and CVS)
imports for Arch that were produced in the past year.

Currently, the Launchpad VCS imports are published as bzr branches. Arch
(baz, actually) is still used as an intermediate step in the process. It
is a high priority for me (though I cannot guarantee that the company
will give me the time) to update the back-end to import directly to bzr.

There are definitely plans for converting non-MAIN CVS branches (and for
better support of non-trunk SVN branches), but do not hold your breath.

> > In Bazaar-NG, you would have two branches, and a given checkout must be
> > fully on one branch or the other. I do not understand your use case for
> > mixing branches in a checkout, so I cannot help you find the proper way to
> > address it with bzr.
>  
> The use case I'm familiar with is that we have lots of Perl modules in our
> software, one or two of which have some advanced, experimental features being
> tested which live on a branch. So we check out the CVS trunk everywhere, and
> on those systems we need the new code we do `cvs update -r new_stuff Foo.pm'.
> This avoids having to instantiate a whole branch just to change one file. Of
> course, disk space is cheap these days and branching is a cheap and easy
> operation in most new VCSes, so the arguments in favor of this approach
> probably no longer hold.
> 
> Hope this clarifies things somewhat.

Various solutions are envisioned for this kind of situation. But none of
them is currently being worked on. Off the top of my head:

      * "nested branches": recording the revisions of a collection of
        nested branches. That would allow one-step checkout of a large
        collection of related branches forming a single project. That is
        similar to the "configs" concept in Arch.
      * "partial checkouts": making it trivial to branch by only taking
        a subset of a branch. Toghether with "nested branches" that
        could allow something similar as what you describe.
      * "partial merges": recording merges at file granularity in
        addition to full-tree granularity. Unlike the others solution,
        that does not require splitting the tree into smaller branches,
        but instead allows history-aware merging of different branches
        (like "head" and "stable"). This is probably the most elegant
        solution from a "core model" perspective.

I am not sure this very quick summary is informative for you. In short,
there is definitely interest to addressing this use case, some
interesting ideas have been elaborated, but it's not there yet. 

-- 
                                                            -- ddaa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060317/b11df236/attachment.pgp