confused about push/pull/merge and append_revisions_only

[Talden]

On Mon, Jan 16, 2012 at 8:43 PM, Chris Hecker <checker at d6.com> wrote:
>
>> That is the difference between merging your branch into trunk, and
>> merging trunk into your branch (direction matters)
>
> I think I understand now, thanks everybody.  The bummer is it makes the
> workflow kinda crappy to have to have another clean branch on every
> machine to merge into.  For now I just set it back to False, but I need
> to think more about this.
>
> Thanks,
> Chris

Well a branch yes, working-tree no.  Consider this workflow (OTTOMH,
hopefully it's correct enough to work out any mistakes)

sans colocated branches (core support in the upcoming bazaar 2.5 I
believe) you can do this...

# make a shared repo with branches that won't have working tree...
CMD> bzr init-repo --no-working-trees projectx
CMD> cd projectx

# created the branches
CMD> bzr branch --bind bzr+ssh://.../trunk cleantrunk
CMD> bzr branch cleantrunk feature

# Create a working tree of the feature branch and work on it
CMD> bzr checkout feature work
CMD> cd work
... do work on feature... commit commit commit

# get the cleantrunk up to date and switch your working tree to it
CMD> bzr pull ../cleantrunk
CMD> bzr switch ../cleantrunk

# merge your feature branch and commit
CMD> bzr merge ../feature
... resolve merge, do tests etc... commit (which is to a bound branch)

This demonstrates separation of three constructs in Bazaar.
* A repository of revisions.
* Branches which are pointers into the revision graph + some configuration.
* A working tree that holds the tree state of a branch at a point
along the revision sequence of that branch + uncommitted changes.

Benefits
* You only have one copy of each revision in the repository maing many
operations and storage cheaper.
* You only have one working tree so that's cheaper too
* You have the same bound branch capability explained previously.

By default a branch, repository and working-tree are created together.
 The upcoming core colocated branches feature (currently a plugin)
just adds multiple branches in the same folder rather than one folder
per branch.

--
Talden


> On 2012/01/15 06:37, John Arbash Meinel wrote:
>> On 1/13/2012 10:52 PM, Chris Hecker 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
>>
>>
>>
>> Just to mention, this is the exact behavior you are asking for with
>> append_revisions_only. If you don't have it set, no history is ever
>> *lost* just rearranged. Looking at it from 'bzr log' perspective, what
>> you have right now is:
>>
>> $ bzr log --include-merges trunk
>>
>> ------------------------------
>> revno: 120
>> message: Tip of trunk
>> ...
>>
>>
>> $ bzr log --include-merges mybranch
>> ------------------------------
>> revno: 123 [merge]
>> message: My merge of trunk
>> ...
>>   ------------------------------
>>   revno: 119.1.1
>>   message: Tip of trunk
>>   ...
>> ------------------------------
>> revno: 122
>> message: The last commit of my branch
>>
>>
>> With append_revisions_only=False (the default), we allow you to push
>> mybranch's rev 123 over the trunk branch, because the branch's 119.1.1
>> revision is the same as the current trunks 120 revision.
>> You can see that the revno for the trunk tip revision will have
>> changed. The revision is still in the ancestry, just not at the same
>> place in the graph. With append_revisions_only you have to create a
>> history that looks like:
>>
>> $ bzr log --include-merges correct-branch
>>
>> ------------------------------
>> revno: 121 [merge]
>> message: Merge of my feature
>> ...
>>   ------------------------------
>>   revno: 113.1.10
>>   message: The last commit of my branch
>>   ...
>> ------------------------------
>> revno: 120
>> message: Tip of trunk
>> ...
>>
>> That is the difference between merging your branch into trunk, and
>> merging trunk into your branch (direction matters).
>>
>> John
>> =:->
>>
>