Bzr needs a simple way to prevent revision history changing order on shared branches
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Fix Released
|
Low
|
Aaron Bentley | ||
bzr (Debian) |
Fix Released
|
Unknown
|
Bug Description
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.
Related branches
description: | updated |
Changed in bzr: | |
status: | Unknown → Unconfirmed |
Changed in bzr: | |
importance: | Undecided → Low |
status: | Unconfirmed → Confirmed |
Changed in bzr: | |
status: | Unconfirmed → Fix Released |
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.