centralized workflow and tracking upstream questions

[Andrew Bennetts]

Tom Vaughan wrote:
[...]
> bzr init website/branches/vendor
> bzr init website/trunk
> bzr branch -r0 website/branches/vendor website/tags/template-0.1
> bzr branch -r0 website/branches/vendor website/tags/template-0.2

Here's the fundamental confusion, I think.  Doing "bzr branch -r0 ... foo" is
the same as doing "bzr init foo".  A branch with no revisions is exactly what
"bzr init" produces. 

[...]
> cd vendor
> bzr merge file:///srv/bzr/website/tags/template-0.2
> 
> bzr: ERROR: Branches have no common ancestor, and no merge base
> revision was specified.
> 
> Why is this? The tags share a parent branch. Or am I just completely
> off the mark on how this *should* be done.

What's happened here is that you made the tag branches with no history (i.e. no
revision), so thus they have no common history with anything.  So the message is
correct and expected.

Rather than creating these tag branches from "-r0" (i.e. no revision),
you probably want create them from an actual revision of an existing branch.
Then the rest of what you tried ought to work as expected.

[...]
> Bonus Question: Why the use of "--unchanged" on some of the check-ins
> above? As I understand it I still need to check-in after the merge so
> that the updates are propagated to the centralized repository. No? So
> why would bzr tell me there's nothing to check-in when "--unchanged"
> is omitted? If I run `bzr log` after the check-in I have two new
> revisions which appear to be exactly the same.

You need "--unchanged" there because there were no changes: your "bzr merge"
invocation would have reported "Nothing to do.", i.e. no new revisions were
found in the branch being merged in.

You can verify that nothing changed after such a merge by running "bzr status",
which will show no changes to files, and no "pending merges".

I hope this helps,

-Andrew.