Bzr externals for bzr and bzr-svn

[Jelmer Vernooij]

On Wed, 2010-04-14 at 11:29 +0300, Alexander Belchenko wrote:
> Jelmer Vernooij пишет:
> > 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). 
> Is there any docs/examples on how bzr-externals could hook in the 
> support for externals? I think such support should not be n bzr-svn at 
> all, because it clearly requires presence of externals plugin to work.
bzr-externals would have to register a custom mapping format, see
mapping.py in bzr-svn for the base class. You could derive it from
BzrSvnMappingv3 if you don't want to reimplement all of the mapping
logic.

Some initial work on nested trees I did earlier is here:
lp:~jelmer/bzr-svn/nestedtrees2, though I'm not sure how well it works
these days or how well it merges into trunk....

We'd probably have to make some changes to the fetch code to call out to
the mapping format to allow it to deal with externals. I'll see if I can
make the changes for that in the next couple of days.

> >> 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. 
> I think it could be much simpler if we relax the requirement of 
> round-tripping. Actually bzr-externals don't need to have 
> .bzrmeta/externals file to be committed if user only care about checkout 
> of the latest revision of svn tree. So all required files for 
> bzr-externals could be generated in the create working tree phase and 
> then trigger specific action in bzr-externals to get the external branches.
This would mean that information has to be stored somewhere external, as
you need to access it after the fetch process has finished. The fetch
process doesn't receive any information about what sort of working trees
are created afterwards. Furthermore, you would need to access this
external store e.g. when you revert the working tree to an older
revision, etc.

If you drop the requirement of roundtripping altogether (which is
possible with bzr-svn's infrastructure) that means it won't be able to
push revisions with your externals-enabled mapping format, it would only
be possible to dpush. 

> > 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).
> So it will be nice if bzr-externals would provide universal way to add 
> "nested trees emulation" to all three. As I can see there is still big 
> road ahead before native nested trees would be landed into the core. 
> Actually they are already one year held on the shelf.
The problem is that this means inconveniencing our users with a mapping
bump twice. I don't want to do that, not in mainline bzr-{svn,git,hg}.
If we really care enough about nested trees we should overcome the
obstacles and see what the best way forward is, rather than trying to
hack around the fact that they're missing.

> So, I'd say they 
> could be there another year or so, and I won't be surprised. So your 
> position, Jelmer, is understandable, but let's be pragmatic here: we 
> have emulation and we can find the way to plug it into bzr-$VCS and many 
> people will be happy to see it even in the limited fashion.
I don't think this is pragmatic at all, we will perhaps be able to
deliver the feature a bit earlier to the users but would inconvenience
them later with mapping upgrades.

Cheers,

Jelmer