Bzr bind/unbind ideas

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicholas Allen wrote:
> do a bzr update first. This is necessary of course but the real problem
> is that this now changes how the history will be presented on the
> mainline because my revision now gets "wrapped up" in another revision.

All the original revisions are still shown, though.  Is that really such
a problem?

> What I was thinking is when you push to a location bzr would ALWAYS
> assume it is bad to change the order of the revision history at the push
> location.

I think that's a step backwards.  The way I work, it is useful to have a
push command that reorders revision history.  I think the earlier
suggestions to have branch control history reordering are better.  It
would also control pulling into the branch.  And that would fix some of
the bzr release process.

Currently, Robert recommends that when a release branch is made, bzr.dev
should do a partial merge.  This strikes me as crazy, because fixes
should flow easily from the release branch into bzr.dev.  But Robert's
rationale is that he doesn't want to be able to accidentally pull
bzr.dev into the release branch.  By setting the "no-reorder" flag, we
could prevent the accidental pull without doing partial merges.

> 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.

The closest thing we can do is create new versions of the revisions that
*do* include the changes introduced by the last upstream version.  These
will, at minimum, have new revision-ids, and may also have other
metadata differences.

Personally, I think that's a very heavyweight solution to a pretty
insignificant problem.

Have you considered just changing the way logs are displayed?

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFcaMS0F+nu1YWqI0RAoYbAJ44DBJOiGW+uOYVcfZ287QQfPxXBQCbBldP
r1flO4lrD2Rx2diVcQtWc4s=
=ki8u
-----END PGP SIGNATURE-----