migrating from CVS

[Jos Backus]

On Mon, Mar 06, 2006 at 01:51:30AM +0100, David Allouche wrote:
> On Sun, 2006-03-05 at 13:17 -0800, Jos Backus wrote:
> > So I have been looking into conversion tools and found tailor.  One thing I
> > noticed immediately is that tailor doesn't handle module targets with
> > subdirectories, e.g. `foo apps/foo'. This appears to be a bug.
> 
> 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?

> > As I understand it, the Bazaar-NG model is that one has a checkout (tree)
> > for every branch, whereas with CVS there can be one tree but checket-out
> > files can be on different branches. We use this feature to introduce new
> > software in an otherwise stable tree.
> 
> As far as I know, CVS is the the only system that allows a checkout to be a
> mixture of things from different branches. It's generally a bad idea to do
> that because such a state cannot easily be recorded. With CVS you can
> _actually_ do some really crazy things (with default branches and such), but
> there _are_ ways of solving the same use cases that do not involve killing
> puppies.
 
Apparently Subversion supports this as well.

> > Say I have a CVS checkout with 1000 files, all of which are on the trunk
> > but one file lives on a branch. Does this mean that in Bazaar-NG land I
> > would have two almost identical trees except for the one file?
> 
> 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.

> With 0.8, you will not need to actually have two full trees like now.
> Instead you will have the ability to have a "shared repository" that
> contains several branches which only contain version control data, but not
> the actual source files. Then you will "checkout" from those branches to get
> the sources files to work on.
> 
> Pretty much like CVS or SVN actually, except with all the benefits of
> decentralised version control: per user repositories, disconnected
> operation, useful merging, etc.  -- -- ddaa

Great. It's the distributed nature of Bazaar-NG with all its useful features
that I think is the biggest argument for choosing it over Subversion.

-- 
Jos Backus
jos at catnook.com