merge vs pull

[Kevin Smith]

Erik Bågfors wrote:
> As another RCS user (and not a RCS developer) I have to agree. I
> rather have two commands that does two very defined things (no
> suprices) than one command that does two things. I think pull and
> merge are two very different operations, used for two different
> purposes.

I think I have been persuaded that there should be separate commands. 
Now, the issue to me is how clearly the docs distinguish between the 
two, and what the app displays to the user after each operation has been 
performed.

Is there a compelling reason it's called "pull" instead of the old CVS 
favorite "update"?

Martin said of pull: "This can only succeed if the source is a 
descendent of the tip of the target." If you run it when this is not the 
case, the message must tell the user what to do. (Maybe it already does).

Does pull modify both the archive and the working tree (at least by 
default)? I tried to answer this myself, but I don't have bzr installed 
here right now, and I couldn't find any online bzr reference docs (!)

If you try to pull with uncommitted changes, the error message should be 
clear.

After a merge, assuming the working tree has changed and the archive has 
not, the app should remind the user that a review and commit are required.

Does merge behave differently with and without uncommitted changes? If 
you try to merge with uncommitted changes, it should refuse by default 
(I think it already does?). Is merging from an identical branch an 
error, or a noop? What about merging from a descendent (the case where 
pull would have worked)...that should succeed with a reminder to commit, 
which would mean that someone could always choose merge+commit and never 
have to learn/use pull.

Kevin