updating checkouts with no upstream changes

[James Westby]

On Tue, 2008-05-13 at 07:32 -0500, Russ Brown wrote:
> I think I actually prefer Stefan's solution: if update can't act with 
> merges being needed, it should refer you to the merge command so you can 
> get back in sync that way. At least that way you have to option to not 
> bother with the update and carry on committing locally for a while 
> before you do decide to merge.

Hi,

Can I ask what you think using bound branches (heavyweight checkouts)
buys you in this situation? All that would be different if you were to
switch to normal branches would be using "commit" instead of "commit
--local", "pull" instead of "update", and "push" instead of "commit"
without local, and you can always "bind" if you want to make several
commits without having to push each one.

Also, isn't there a distinction in bzr between the branch that is the
default for "merge", and the branch that is default for "pull"? That
would seem to either lead to problems if the user had the merge location
set to something they didn't expect, or possibly needless extra 
difference between the behaviour when a branch is bound and when it 
isn't.

However, using "merge" to do something that requires a merge is a 
reasonable idea, and would perhaps make it clear what is happening.
My feeling is that it creates too much friction elsewhere, but the
change should be considered.

Thanks,

James