How to communicate with upstream sources intelligently

[Jari Aalto+usenet]

* Wed 2006-06-28 John Arbash Meinel <john AT arbash-meinel.com>
* Message-Id: 44A3021D.7080308 AT arbash-meinel.com
>
> 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.

> 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

>> INITIAL SITUATION
>> 
>>     upstream        import to local TRUNK (bzr init; bzr ci)
>>     v1.0            => imported copy from tar.gz
>> 
>> CURRENT WORK FLOW
>> 
>>     The packages could use some improvements, isolate changes, so make
>>     branch for each:
>> 
>>     local TRUNK        => branch to change-1.0-A
>>                        => branch to change-1.0-B
>>                        => branch to change-1.0-C
>> 
>>     Write code, test, and submit individual patches to
>>     upstream from the branches (bzr diff):
>> 
>>         patch-1.0-A
>>         patch-1.0-B
>>         patch-1.0-C
>> 
>>     Upstream accepts A, and C. Did not yet respond to B. In the mean
>>     while time passes and upstream releases v1.1, which needs to be
>>     imported to TRUNK to make it current.
>> 
>>     upstream        local TRUNK (bzr ci)
>>     v1.1            => untar *.tar.gz and "ci" this as "1.1"
>> 
>>     Now, the branches A and C are no longer needed, but
>>     what should be done to B? Suppose that the source has
>>     changed significantly, so what is the easiest way
>>     to merge
>> 
>>         1.1 + changes in branch-1.0-B 
>> 
>>     to make it branch-1.1-B and submit that to upstream?
>> 
>> I'm sure I'm not using brz to its fullest potential yet, so please
>> welcome improvements and ideas that might work better.
>> 
>> Jari
>> 
>> 
>>