Re: Importing Bzr revisions

From: Shawn O. Pearce <spearce@spearce.org>
Date: Mar 23, 2009, 13:55 UTC
Message-ID: <20090323135504.GA9732@spearce.org>
In-Reply-To: <03AC7EDA-2A9F-4626-A67B-CE9F2A88FC7D@gmail.com>

David Reitter <david.reitter@gmail.com> wrote:

Show 5 quoted lines

>
> I'm just experimenting with "bzr fast-export", which converts to git,  
> and it seems to take about 4 minutes for 1000 revisions on our (modern) 
> server.  That would be around 7 hours for my emacs repository; I can't do 
> that daily.

No, you'd want to incrementally do that...

> I wonder if there's a way for (bzr) fast-export / (git) fast-import to  
> work incrementally, i.e. for selected or most recent revisions.

fast-import supports incremental use; git-p4 does it from Perforce. The trick is the application writing the stream (bzr fast-export in this case) needs to do something to pick up the prior revisions. It might do that by using the same mark numbers, and requiring you to use --import-marks and --export-marks on the git side to save the mark database between runs. I don't know, I haven't looked at it.

> Or, one could do something like  bzr diff -r $REV.. $BBRANCH |  (cd  
> $GBRANCH; patch -p0; git commit), plus preserving authors and log  
> messages.   Is this roughly what the fast-export format does anyways?

Eh, sort of.

The fast-import format works on whole files, not patches. So we have to get the entire file from bzr each time it is modified. If the file is a small source file, you almost can't tell the difference in performance. If its a huge binary that changes often, it hurts to keep dumping the entire thing over the stream.

But at the commit level, yes, it preserves authorship and log messages, assuming the bzr fast-export program incldued that data. And I'm rather certain it does.

-- 
Shawn.