Bzr externals for bzr and bzr-svn

[Alexander Belchenko]

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). 

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.

> 
>> 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.

> 
> 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. 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.

> 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. 

Let ask Eugene and if he willing to work on this feature then I'll help him.

Евгений, что скажешь?

Alexander