How to communicate with upstream sources intelligently

John Arbash Meinel john at
Thu Jun 29 00:06:48 BST 2006

Hash: SHA1

Jari Aalto+usenet wrote:
> * Wed 2006-06-28 John Arbash Meinel <john AT>
> * Message-Id: 44A3021D.7080308 AT
>> If I understand correctly, all 3 changes were done on separate branches.
> Yes, but should I use "init-repo" and branch inside it? I'm still
> learning what would be the best way to use the tool.
>> Is there anything preventing you from doing:
>> bzr branch TRUNK-1.0 TRUNK-1.1
>> cd TRUNK-1.1
>> # update from 1.1.tar.gz
>> bzr commit -m "version 1.1"
> Sure. What I had in mind is that I keep all upstream
> version in common line, so that it is possible to
> see easily what has changed between 1.0 and 1.1
>     TRUNK => 1.0 => 1.1
> In your version the branch is separate with disk space as well.
> Could you elaborate this a little more.

It doesn't have to be. You could do:

cd ~
bzr init-repo --trees project
cd project
bzr init TRUNK-1.0
cd TRUNK-1.0
(untar the tarball)
bzr add; bzr commit -m "release 1.0"

cd ..
bzr branch TRUNK-1.0 TRUNK-1.1

>> cd ..
>> bzr branch TRUNK-1.1 change-1.1-B
>> cd change-1.1-B
>> bzr merge ../change-1.0-B
>> # Resolve conflicts
>> bzr commit -m "Ported change B to 1.1"
> This pieace was what I was missing.
>> The point is to create a pristine 1.1 from the pristine 1.0 (to preserve
>> file ids), and then just create a working branch for 1.1-B, and merge
>> the old changes into it.
>> It should pick a valid base since it came from the same tree that 1.1 is
>> coming from.
>> Am I missing something in your workflow?
> Perfect. Did you spot anything that could be, in principle, done
> better or track changes more effectively?
> Jari

In the future you could use the svn plugin that Jelmer is working on, to
natively get changes from an svn repo. (But that is still a work in

Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Using GnuPG with Mozilla -


More information about the bazaar mailing list