Question/idea about multiple developers committing to one branch

[Nicholas Allen]

> ... and have the advantage that than merge could have an argument
> (--to), that would cause the parents to be recorded in reverse order, so
> than the developer would just 'bzr merge --to mainline; bzr commit; bzr
> push mainline' This would change their local revnos(*), but would properly
> reflect the project structure in log structure (and revnos on the
> mainline).
That would be great too! But I'm wondering how bzr could prevent 
something an annoying situation like this:

Imagine there is a smart server that will not accept pushes that change 
the order of the existing revisions. The user has their own branch and 
they want to merge into the mainline so they merge first from mainline 
and then try a push. The thing is they forgot to use the --to option so 
the server complains because they will be changing the order of the 
revisions in the mainline. But what happens if the user did a lot of 
conflict resolving when they merged from mainline so they could not just 
revert the merge and then redo it with the --to option as they would 
loose all their conflict resolutions.

Ideally  you would want a command that could reorder local revisions so 
that they could be pushed to the smart server with these kinds of checks 
on. So instead of it being on the merge command perhaps it would make 
more sense if it were on the push command or if it were a separate 
command altogether.

eg:

bzr merge mainline
...fix conflicts...
bzr push mainline

error: Your push would change the order of revisions.
This can be prevented in the future by using a bound branch or checkout.
You can reorder your local revisions so they will be accepted by the 
server by running "bzr reorder-for-push mainline"
and then try your push again.

Or push could detect the error automatically and just reorder the local 
revisions but I'm not sure if any of this is even possible. Can you 
reorder revisions after they have been committed without affecting the 
branch in anyway?

Otherwise, what would the user be expected to do if they forgot the --to 
option to the merge command.

Is there a way this could be handled in an easy and transparant way for 
the user?

Perhaps another alternative is when they merge from a location, bzr 
could tell somehow this was a location that didn't allow reordering of 
revisions it would reorder the local revisions so the --to option would 
never have to be specified. Depending on the merge source it would 
determine this automatically and reorder the local revisions if necessary.

Lots of questions here and I'm just brain storming so a lot of these 
ideas are not well thought out. Anyone else have suggestions?

Cheers,

Nick