Re: [Monotone-devel] more on commit without -b option

[Timothy Brownawell]

On Sun, 2007-11-11 at 20:48 -0700, Derek Scherger wrote:
> After a brief chat on irc today I was left with the following
> impressions as to where this might go.
> 
> - remove -b from commit (Thomas Keller already has this done)
> - add a mtn branch command for creating new branches that sets the
>   workspace branch option for future commits. This should fail if the
>   new branch already exists (Thomas has this done too although I'm not
>   sure it fails if the target branch exists).

What if I *want* to commit to an existing branch, say because a straight
'propagate' gives tree conflicts? Right now I could checkout the source
branch, rearrange things, commit to the target branch, and merge. I
guess this would just mean to have a way to override the
fail-if-target-exists check.

This also seems like a bit of a conceptual change, in that it creates an
action of "branching" as opposed to the underlying and currently exposed
"eh, let's put this revision someplace else". So branches are
conceptually a bit less lightweight now. I suppose there is something to
be said for conforming to what expectations people have already learned,
I just wonder if it sounds too much like "CVS done right".

> - remove the -b option from update and require that update stay on the
>   workspace's current branch (i.e. fail if the specified rev is *not* on
>   the current branch)
> - add an mtn switch command that switches the workspace to the specified
>   branch. Optionally allow -r to specify a particular revision in the
>   target branch. Require the target branch to exist or fail.

Well, it's better than how update handles branches currently...

> - see what other commands we can remove the --branch option from
> - see if we can remove make_branch_sticky and friends

Cool.


-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net