Bzr externals for bzr and bzr-svn

[Jelmer Vernooij]

On Mon, 2010-04-12 at 17:10 +0100, Tom Widmer wrote:
> Jelmer Vernooij wrote:
> > On Mon, 2010-04-12 at 13:31 +0100, Tom Widmer wrote:
> >> Jelmer Vernooij wrote:
> >>> Hi Patrick,
> >>>
> >>> On Mon, 2010-04-12 at 13:20 +1200, Patrick van der Velde wrote:
> >>>> I've been experimenting with bzr at work. Creating a bzr 'working
> >>>> directory' from our SVN repository is very simple and super quick!
> >>>> However I haven't been able to make the svn-externals directories show
> >>>> up in the bzr 'working directory'.
> >>>>
> >>>> I've installed bzr-externals (v1.3) but for some reason bzr-svn
> >>>> doesn't import the externals directories from the svn repository. Is
> >>>> there a way to make bzr-svn get the externals?
> >>> There is nothing in Bazaar that bzr-svn could map externals to. Nested
> >>> trees have been discussed, but it doesn't look like they will land any
> >>> time soon and unfortunately this also means that svn externals won't be
> >>> supported in bzr-svn any time soon.
> >> As a short-medium term solution, would it be possible to use the 
> >> bzr-externals plugin? Presumably you'd just have to populate the 
> >> relevant .bzrmeta/ files during import, but perhaps this would cause 
> >> backwards and forwards compatibility issues (and obviously you could 
> >> only round-trip bzr externals that reference svn branches).
> > That's not really an option - it would require changing the mapping
> > format, and this affects all existing bzr-svn users. I don't want to do
> > that for something that's only temporary. Furthermore, there are
> > alternatives to bzr-externals and why would we pick bzr-externals rather
> > than e.g. config-manager or scmproj?
> Could it be an optional part of the mapping? I imagine mapping options 
> aren't to be encouraged, since independent bzr branches created from the 
> same svn branch with different mapping options would not be interoperable.
What you're basically suggesting is having another mapping format that
users could select. Having two different "current" mappings will cause
confusion when users are unable to merge from each other because they
used different mappings. 

That said, I'm not necessarily opposed to this, but I don't have any
interest in pursuing it myself - I'd rather spend time to work on
getting proper nested tree support into Bazaar. Also, such a mapping
could actually live in the bzr-externals plugin, it doesn't have to be
in bzr-svn (bzr-svn allows other plugins to register mappings). 

> The only reason I raise it is that nested trees have remained in the 
> pipeline for several years now, and this is probably an adoption blocker 
> for many users who make use of Subversion externals. Having bzr co 
> svn_branch just work, even when there are externals, would be a major 
> bonus, and perhaps you'll be able to reuse most of the implementation 
> when you make it work with nested trees...
The lack of nested trees is also a blocker for a lot of people who want
to use Bazaar natively. 

Getting the bzr-externals support in bzr-svn mappings right is tricky
and quite a bit harder than with nested trees because it uses a file
in .bzrmeta, which causes complications when roundtripping. 

Furthermore, it's not just bzr-svn that would have to get support for
bzr-externals and then later converted over to nested trees - there's
also bzr-git (submodules) and bzr-hg (subrepos).

To reiterate, these are my personal reasons for not working on a
bzr-externals mapping for bzr-svn, I don't think it's necessarily a bad
idea. If anybody else is interested in working on this, I'm happy to
answer questions they may have. 

Cheers,

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