Bzr needs a simple way to prevent revision history changing order on shared branches

[Nicholas Allen]

When multiple developers share the same branch and push to it, it is possible that the revision history order changes. So revision 10 represents a change by one developer at one point in time but after a few merge and push operations by the various developers at a later time revision 10 is no longer the same change by the same developer. This is almost always undesired for a shared branch. Currently, the only option available to ensure this is to setup PQM and have it as the only one that pushes into the shared branch.

If all developers use checkouts or bound branches the revision history will not change order but if some developers don't do this then this will not be the case.

Bzr needs a way to mark a branch as a shared branch - that is a branch that is pushed to by multiple developers. In the dumb file servers this would create a file in .bzr to indicate this. Perhaps a command like:

bzr shared branch-location

Then when a user tries to push to this branch location bzr will check if it is a shared branch or not. If it is and the push will change the order of revisions then it prints an error message:

bzr push mainline
Error: The destination branch location is a shared branch and your push will reorder the revisions. You should use a checkout/bound branch in order to commit changes to this location.
You can make this branch a bound branch by running 'bzr bind mainline'. You will then need to update your branch by running 'bzr update'. Then you can run bzr commit to commit your
changes to this location.

[Martin Pool (mbp)]

I think there is some use for a policy that says "you should only append to this branch, not switch". This could be reasonably enforced by an acl in the smart server.

[John A Meinel (jameinel)]

I think we could also have the client enforce this in a general sense.

It wouldn't be an absolute enforcement, since with plain filesystem commands, you don't really have the ability to force this sort of thing. But it wouldn't be hard to have the remote .bzr/branch/branch.conf contain "preserve_mainline=True"

And have the standard client refuse to push revisions which would change the existing revision history of the target branch.

We would need a branch format bump, to ensure that older clients won't try to update a branch with that flag set. But I don't see it requiring a smart server.

The smart server is just another layer that can be even more strict about enforcing it.

[Nicholas Allen (nick-allen)]

Yes that would be great! The smart server would be able to guarantee it
but for the dumb file systems it would be up to the client to ensure it
respects the flag.

[Aaron Bentley (abentley)]

Branches created with the --append-revisions-only flag in Bazaar 0.15 have the desired behavior.