bzr svn-import with a deep branch layout

[Russ Brown]

On Tuesday 27 October 2009 04:51:53 pm Algis Kabaila wrote:
> On Wednesday 28 October 2009 02:28:05 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?
> 
> My personal "work around" solution is quite simple (and I love things that
>  are simple!).  Since I moved from my "private repository" (*) method to
>  svn, I noticed that I very seldom if ever went back to an earlier
>  committed version. Sure, the history was important, but as soon as the
>  project reached a stage where I could say "ready for use", I moved a copy
>  of the trunk to either branches or even tags subdirectory (as recommended
>  by svn masters).
> 
> So that in branches history was important, but not the capability of
>  reverting back to an earlier version.  So I moved a *snapshot* of my "svn
>  branches" and also a log of their *history*,
> 
> When creating the first "bzr branch", used the -F option, which copied the
>  svn log into the first login message.  This can see in the "legacy branch"
>  of the project "easmy":
> bzr log lp:~algis.kabaila/easmy/fem
> I don't know if you can see it, as I get asked by my system for the access
>  to my private key (I am told that it is *my* OS that asks for it, but I am
>  not sure, as it has not been tested by others.)
> 
> In this manner all the problems associated with moving large repositories
>  from svn to bzr were avoided.  The cost is the loss of ability to revert
>  to an earlier version from the "svn branches" and for that I can go back,
>  at least for a while, to the svn repository.
> 
> If you are at all interested in "easmy", please look at the wiki page:
> https://wiki.ubuntu.com/easmy/
> 
> I realise that this is a mere work-around and may not suit you, but it does
> suit me.
> 
> OldAl.
> PS:my "private repository" was a FILO queue of directories on my own
>  external hdd,
> A.
> 

Thanks for the suggestions. In our case, our development bzr migration was 
done ages ago: we just decided to take the opportunity to clean the codebase 
up and start with a completely fresh set of repositories, leaving the old svn 
repository in a dormant a read-only state.

However, digging through history on it is a royal pain. More often than not, 
you encounter an svk merge with a monstrous commit message, where digging into 
the merged revisions is pretty much impossible.

That's why I'm trying to import it into bzr: since svn-import follows svk 
merges, it will be far easier to dig through history using qbzr.

The good news is that I think I have found a way to workaround this problem. 
First, you need a list of all branches ever created in the history of the 
repository [1], and then set the branches setting in the appropriate place in 
subversion.conf (I also added trunk/ to this list to following the docs on the 
setting). With this in place, the import seems to be doing a *lot* better, and 
is actually properly picking up branches and is also handling some of the 
merges properly too.

I'm not even halfway through the revisions yet, but it's looking good. I'll 
update if/when it's done to report on things like repository size (the svn 
repo is 13G: it will be interesting to see what size this 2a repository ends 
up being).

However, I would like to know if there is any reason why svn-import cannot do 
this itself: detecting a branch creation can be as simple as spotting a copy 
of trunk to anywhere under a specific folder. It would be nice if it could do 
it on the fly.

[1] Getting a list of all branches ever created from trunk should be possible 
using something like this:

svn log -v --xml file:///path/to/repos/branches | xmlstarlet sel -T -t -m 
"/log/logentry/paths/path[@copyfrom-path='/trunk' and @action='A']" -v . -n | 
sort | uniq > all_branches_ever

In my case however this didn't work, as our monstrous svk merge commit 
comments exceeded a libxml limit that I was unable to disable. The xml log 
output from the svn part of the command above was 1.5G. I went through 
attempts in four other languages before finally finding that C# (via mono) was 
able to do it. I can post the (simple) code if anyone would find it useful.

-- 

Russ