centralized workflow and tracking upstream questions

[Neil Martinsen-Burrell]

On Apr 4, 2008, at 2:17 PM, Tom Vaughan wrote:

> On Fri, Apr 4, 2008 at 11:50 AM, Neil Martinsen-Burrell
> <nmb at wartburg.edu> wrote:
>> Tom Vaughan wrote:
>>
>>>
>>> On Thu, Apr 3, 2008 at 1:52 PM, Neil Martinsen-Burrell<nmb at wartburg.edu 
>>> >
>> wrote:
>>>
>>>>
>>>> Tom Vaughan<tom<at>  software6.net>  writes:
>>>>
>>>> To do this with a centralized repository, you should be able to  
>>>> just
>> create
>>>> site/vendor and site/mysite as (lightweight-) checkouts of some  
>>>> remote
>> branch.
>>>> Then, each commit will propagate to the bound remote branch when  
>>>> it is
>> locally
>>>> committed.
>>>>
>>>
>>>
>>> I think I did this correctly. This is one point I'm really perplexed
>>> about. I'm sorry if this is covered elsewhere. But when I import the
>>> first vendor version, and then merge that onto the trunk for the  
>>> first
>>> time, I wind up with all the files from the vendor branch added to  
>>> the
>>> trunk. At this point I still haven't checked them in (I did a `bzr
>>> init ...` and a `bzr co ...`), but yet I can't check-in unless I
>>> specify --unchanged. And after I do, I wind up with two new  
>>> revisions.
>>> Why? The first from branch nick "vendor," the second from branch  
>>> nick
>>> "trunk." When I do subsequent imports of other vendor releases, and
>>> merge those onto the trunk I don't have to provide --unchanged, and
>>> when I check-in I only wind up with one new revision.
>>>
>>
>> I'm not sure that I understand what you are talking about here.   
>> Can you
>> show commands and output from an actual session so we can be on the  
>> same
>> page?  What is the result of ``bzr st`` after you merge the vendor  
>> branch
>> onto the trunk?  What do you mean when you say "I can't check in  
>> unless I
>> specify --unchanged"?  Is there an error message when you try to do  
>> what you
>> want?
>>
>> We should be able to sort this out with more information.
>
> $ mkdir website
> $ bzr init-repo website/
> $ mkdir website/trunk
> $ bzr init website/trunk/
> $ mkdir -p website/branches/vendor
> $ bzr init website/branches/vendor/
> $ bzr co website/branches/vendor/
> $ cd vendor/
> $ bzr import ../template-0.1/ .
> $ bzr ci -m "imported vendor release 0.1"
> Committing to: /home/tvaughan/website/branches/vendor/
> added index.html
> Committed revision 1.
> $ cd ..
> $ bzr co website/trunk/
> $ cd trunk/
> $ bzr merge ../vendor/
> +N  index.html
> All changes applied successfully.
> $ bzr st
> working tree is out of date, run 'bzr update'
> $ bzr ci -m "merged vendor release 0.1"
> Committing to: /home/tvaughan/website/trunk/
> bzr: ERROR: no changes to commit. use --unchanged to commit anyhow
> $ bzr ci -m "merged vendor release 0.1" --unchanged
> Committing to: /home/tvaughan/website/trunk/
> Committed revision 1.
> $ bzr log
> ------------------------------------------------------------
> revno: 2
> committer: Tom Vaughan <tvaughan at lindero>
> branch nick: trunk
> timestamp: Fri 2008-04-04 12:13:44 -0700
> message:
>  merged vendor release 0.1
> ------------------------------------------------------------
> revno: 1
> committer: Tom Vaughan <tvaughan at lindero>
> branch nick: vendor
> timestamp: Fri 2008-04-04 12:12:16 -0700
> message:
>  imported vendor release 0.1

I believe the reason that this is happening is because the trunk  
branch (yes, it is a branch in bzr terms) is unrelated to the vendor  
branch, even though it is just an empty branch.  Thus, merging the  
vendor branch into the trunk gives the surprising message "working  
tree is out of date, run bzr update"  (and doing it doesn't fix the  
problem).  I've found two workarounds.  The first is to create the  
trunk by branching the vendor location in the first place, e.g.

$ bzr init-repo website
$ bzr init --create-prefix website/branches/vendor
$ bzr co website/branches/vendor
$ bzr import template-0.1 vendor
$ bzr ci -m 'vendor drop' vendor
$ bzr branch website/branches/vendor website/trunk
$ bzr co website/trunk
$ cd trunk; bzr merge ../vendor # Nothing to do here (yet)

The other workaround is to make the initial merge into the trunk with  
``bzr pull`` or ``bzr merge --pull`` which will make trunk (at least  
initially) a mirror of the vendor branch and will succeed, since there  
are (trivially) no revisions from trunk that aren't merged into the  
vendor branch.

It is still possible that there is some sort of bug here.  The  
behavior of marking trunk as out of date after merging vendor, and the  
brokenness that results if you try to ``bzr up`` as suggested lead me  
to believe that there may be something up, but my bzr-fu is not strong  
enough to suss out what it is.

I prefer the first choice of making the trunk branch by branching the  
initial vendor drop, because it emphasizes the inter-relationship  
between the two branches.  Perhaps there is a cultural svn-vs-bzr  
difference here, because svn will gladly merge unrelated branches  
because it sees merging as a form of applying a patch, whereas bzr  
thinks of merging in terms of the entire ancestry of the branches.

-Neil