Question/idea about multiple developers committing to one branch

[Nicholas Allen]

> 
> I think you should not force the user to bind to the branch,
> he might work off-line a lot and do lots of local commits,
> it will be nice to allow him this functionality
> without requiring him to bind, this might be where the --to
> could be usefull

I think this is not needed. If you just change push so that it never
changes revision history order at the push location then this problem
never arises. The update command (or some other command) could be used
on a non-bound branch too. You could also provide a location to the
update command. In effect the update command would prepare a branch so
that it is in a suitable state for pushing to a given location. That is,
it has all the latest changes at location and it will only append to the
revision history when pushed.

Maybe it makes sense to use a different command name for this instead of
update (as this is used to update the working tree) but the concept I
think is a sound one and ensures that revision history order never
changes at the push location.

Thus bound branches are nothing more than an added convenience. You can
still do the same without binding and without checkouts too. You just
try pushing somewhere and if not possible run update on that location
and then push again.

I think it gets confusing that bzr can reorder the revision history.
This can even be a problem with only one developer who uses multiple
branches that he feeds into one central branch. You can work around this
in this case by using an integration branch and only pushing from this
branch but that is more work and is not really possible when sharing the
branch with multiple developers as someone else might have pushed there
again in the meantime.

I would much prefer it if bzr worked in this manner. It would reduce the
concepts that a user has to learn. They would not have to think about
bound branches or not and what are the differences between bound and
unbound as these concepts would be unified and supported by every
branch. It also eliminates the somewhat confusing messages that -1
revisions were pushed and possible confusion due to revision history
changing order.

It would also be simple to setup. If I want to share my branch with
multiple developers I just have to make it writable by them and *know*
that the revision history will not be reordered due to others working on
my branch.

The --overwrite option to push could be used to allow revision order
changing in the push location but this would not be the default.

Nick