bzr svn-import with a deep branch layout

[Jelmer Vernooij]

On Wed, 2009-10-28 at 16:05 -0500, Russ Brown wrote:
> On Wednesday 28 October 2009 12:57:41 pm Jelmer Vernooij wrote:
> > On Tue, 2009-10-27 at 10:28 -0500, Russ Brown wrote:
> > > On Tuesday 27 October 2009 10:05:21 am John Arbash Meinel wrote:
> > > > Russ Brown wrote:
> > > > > Are my suspicions correct, and if so is there any way to get
> > > > > svn-import to detect branches by noticing copies of trunk, rather
> > > > > than simply looking for subdirectories of branches?
> > > > >
> > > > > Thanks.
> > > >
> > > > I'm pretty sure you can teach bzr-svn about custom branching schemes. I
> > > > don't remember all of the details, though.
> > >
> > > That would probably help, though one complication is that to begin with
> > > we did create branches directly beneath "branches" before switching to
> > > categories as the number of branches we had somewhat exploded. I'm not
> > > sure how well it would handle the overlap period.
> > >
> > > I do however seem to remember Jelmer talking some time ago about the
> > > branch layouts being phased out in favour of branch detection based on
> > > the copy source, though I could be wrong.
> > >
> > > Here we go: https://bugs.launchpad.net/bzr-svn/+bug/130372
> > >
> > > Doesn't really explain what the new mechanism is though.
> > 
> > You can use "bzr svn-layout" to see what sort of repository layout
> > bzr-svn thinks it should use for a particular repository.
> > 
> > See "bzr help svn-layout" for more information on manually setting the
> > repository layout that should be used. You can use wildcards.
> Yes, see my other mail on this thread about how I'm making use of this feature 
> to solve the problem using something of a brute-force method.
IIUC you're not using wildcards though - are the branch paths that
strange?

> > We can't just rely on considering everything that is derived from trunk
> > as a branch, as this assumes that there is a main branch - which is not
> > necessarily true. It would also require finding the ancestry of all
> > directories in the latest revision to see if they derive from trunk,
> > which would have performance consequences.
> > 
> 
> Granted, but couldn't this just be another repository layout definition? i.e. 
> "One defined trunk, with a directory tree of branches with arbitrary nesting".
> 
> There are obviously things I don't know about this problem domain as I've not 
> spent years working on a tool such as bzr-svn, but it seems to me that the 
> detection would only need to happen at the point of revision import, would 
> only need to look at added directories, and would only need to look for those 
> copied from the defined "trunk" directory. In other words, automating what my 
> brute force method does, and do it on the fly, incrementally. 

In theory it would be possible to do something like that, however it is
far from trivial to do so, as we would need a cache for the results or
every operation includes a full analysis of the repository history. The
user would also need to specify in which revision the trunk should be
considered, as it for example doesn't exist yet in rev 0.

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/20091029/0f5d221e/attachment.pgp