your thoughts wanted on bzr team UDD focus

[Jelmer Vernooij]

On Tue, 2009-12-01 at 13:41 +1100, Robert Collins wrote: 
> On Tue, 2009-12-01 at 02:39 +0100, Jelmer Vernooij wrote:
> > Hi Martin,
> > 
> > On Tue, 2009-12-01 at 12:19 +1100, Martin Pool wrote: 
> > > I'd like to get a sanity check from UDD people on what the Bazaar team
> > > is going to do for our 2.1 release, which will have a feature freeze
> > > in February and go into Karmic.
> > > 
> > > From the previous threads, it seems that the main large things we need
> > > to do are:
> > > 
> > >  * get more code imports working -- investigation of failure causes is
> > > continuing
> > >  * support imports of git submodules or svn externals -- this is not moving yet
> > As for bzr-git/bzr-svn support for git submodules / svn externals:
> > 
> > fwiw git submodules can (as of UDS when I discussed this with Dustin and
> > Vincent) now be imported with newer versions of bzr-git, and are
> > converted to by-reference nested trees. This will of course only work if
> > the target repository supports storing nested trees (e.g. the
> > experimental development-subtree format). 
> 
> This makes me extremely nervous. The last time a plugin did something
> the core didn't /support/, it took us 4 and a half years or so to fix
> it, because we were constrained by having lots of data around, and we
> didn't get to do the fix that would have been best (and been maybe 10%
> smaller on the converted data).
Last time this happened we required a particular format for all  
 bzr-svn/bzr-git imports, without a particularly good reason. Now it's
 just for repositories that require submodules, there's no proper way  
 to support those with a non-experimental format. bzr-git doesn't
  create development-subtree branches by itself, not even if it sees a
 submodule.

I understand that development-subtree is experimental - this implies
 imports with bzr-git of submodules are experimental too. I don't see
 how bzr-git creating revisions with by-reference nested trees is any
 worse than users doing so manually using "bzr join --reference". Users
 have to manually initialise a development-subtree branch before in either case. 

> _please please please please_ contribute to bzr's support first, and
> only enable this in bzr-git when there is a supported format that does
> nested trees.
While I would love to see proper by-reference nested trees support in
bzr core, I'm very hesitant to contribute given the history of nested
trees in bzr. 

If the current development-subtree format (while clearly marked as
experimental) is bad even for experimentation, can we please remove it? 

> Until then, I suggest outputting one of:
>  - a bzr-builder recipe
>  - scm-proj
>  - config-manager
These three all require additional "magic" versioned files, which are a
pain when roundtripping. 

Also, supporting any of these alternatives now means we'll have to bump
the bzr-git mapping when nested trees land and we do want to create
proper nested trees.

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-distributed-devel/attachments/20091201/b46c1320/attachment.pgp