confused about push/pull/merge and append_revisions_only

[Talden]

On Sat, Jan 14, 2012 at 10:52 AM, Chris Hecker <checker at d6.com> wrote:
>
> I have a repository I push to from multiple places.  I recently set
> append_revisions_only on it, because it's the main server repo, and I
> was always weirded out by a bzr client's ability to modify the existing
> history, which seemed to go against the idea of source code control.
> However, I clearly don't understand something, because now I can't push
> to the repo.
>
> I did a pull, but my local history had diverged (this was expected,
> since I'd done some work locally), so I did a merge from the server and
> a local commit.  Then I went to push, which was my normal workflow, but
> I got this:
>
> Using saved push location: /home/checker/bzr/spyparty/
> bzr: ERROR: Operation denied because it would change the main history,
> which is not permitted by the append_revisions_only setting on branch
> "/home/checker/bzr/spyparty/".
>
> Now I'm not sure what my workflow should be.  How do I push changes back
> to the server repository?  Do I not want append_revisions_only?
>
> Thanks,
> Chris

This scenario is where I use append_revisions_only in any shared
branch and use a bound branch for the feature delivery effort.  A
bound branch is a branch from a parent that is bound to the parent
such that a commit to the branch is first applied to the parent (and
if it fails on the parent it fails on the branch as well).

See the response from John Arbash Meinel as to the differences in the
branch and trunk history that append_revisions_only enforces. This use
of a bound-branch assumes that trunk does have
append_revisions_only=true


Developing a feature
1. Create the feature branch
CMD> bzr branch ...trunk featurebranch

2. Implement the feature on the branch.

CMD> cd featurebranch
CMD> ...
CMD> bzr commit -m "feature is finished. Yay"

3. Delivering the feature to the trunk

3a. Get a bound branch of trunk (or just pull from trunk into your
boundtrunk if you already have a boundtrunk)

CMD> bzr branch --bind ...trunk boundtrunk

3b. Merge your feature branch into your bound trunk branch

CMD> cd boundtrunk
CMD> bzr merge ../featurebranch
CMD> ... resolving conflicts ...

3c. Commit the merge.  This commits to trunk and applies that commit
to the bound branch as well.

CMD> bzr commit -m "New Feature. It's awesome"

If the trunk has changed and the bound branch was not up-tp-date the
commit would fail. At that point revert and re-pull trunk into
boundtrunk before repeating the merge.  I prefer dealing with any
complex merge resolution in the feature branch (by merging trunk into
the feature branch) as part of getting it ready for delivery rather
than in the actual delivery revision itself so reverting the merge
wouldn't be losing any notable effort as that effort would have
already been done and committed in the feature branch.

IMHO you do want to use append_revisions_only=true for the trunk. I
consider that it should probably be the default for branching as it
produces much easier to follow history.

--
Talden