Bzr bind/unbind ideas

[Jan Hudec]

On Sun, Dec 03, 2006 at 12:12:27AM +0100, Nicholas Allen wrote:
> 
> > 
> >>> You would then use the update command (instead
> >>> of the merge command) to update your branch from the push location. When
> >>> you do so it would reorder the revisons in your branch so that the
> >>> changes you made came after the ones at the push location (so your
> >>> changes are added to the end of the revision history).
> > 
> > This is impossible as written.  A revision is a tree snapshot, and if it
> > didn't contain the changes introduced by the last upstream version, it
> > can't appear after he last upstream version.
> 
> But bzr can already do this (or something very similar). If I have a
> branch that I want to push to a location but the push would change the
> order of revisions I can prevent this now by creating a new branch from
> the location I wish to push to and then merge the other branch into this
> new branch and push from that branch instead. The changes made in the
> original branch now appear after the ones in the push location which is
> what I want to achieve.
> 
> So all I am suggesting is that bzr makes this an easier process by not
> requiring you to manually create another branch. I can't see much
> advantage to reordering revisions on a push. To me this always seems
> undesirable and the advantage of preventing this is that you get the
> centralised model without even needing bind/unbind or checkout and
> without loosing any of the benefits of the distributed model. Those
> commands would just exist to make the process more convenient and smoother.
> 
> But I would be happy if bzr provides a simple way to do this and whether
> this is by setting a flag or just always preventing it on a push doesn't
> really matter. As long as bzr has a simple way to make a branch shared
> amongst multiple developers so that the revision order does not change
> then that is the main thing...

In neither case are the changes after each other. They are always
*parallel*.

The log always prints the "merged in" revisions (the ones that come from
argument to merge), indented, first and than the "mainline" revisions
(those that were there before you did merge). The revision numbers are
assigned along the "mainline".

I recently suggested, that merge should have option (and commit should
have it as well for case when you forget to pass it to merge) to swap
the order of parents, so you can choose in which order the parents
should display and revnos should be assigned.

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb at ucw.cz>