Re: [Monotone-devel] Re: [PATCH] mtn commit without -b and mtn branch

[Nathaniel Smith]

On Thu, Mar 08, 2007 at 06:17:15PM +0000, Bruce Stephens wrote:
> "Steven E. Harris" <address@hidden> writes:
> 
> > Bruce Stephens <address@hidden> writes:
> >
> >> One might also want to commit the current workspace to an existing
> >> (different) branch, but I think making that a bit more awkward is
> >> fine.  (So just "mtn commit -b ..." is fine, IMHO.)
> >
> > But "mtn commit -b ..." would still work against a nonexistent branch,
> > as it does today, right?
> 
> Sure.  No reason why it wouldn't.

Well, there is a reason -- it wouldn't add anything useful :-).

"commit -b" is problematic UI (and the source of numerous complaints)
because it gives you exactly one moment in which you have the
opportunity to switch branches; if your attention wanders while
committing, then you lose.  A _lot_ of people have said in the past
that in fact they never use 'commit -b', they just munge _MTN/options
by hand (and actually, I do this too).  So the idea of 'mtn branch'
would be that it lets everyone use this workflow, not just the overly
clever people.

But once 'mtn branch' becomes the usual way to switch branches... what
point is there in making 'commit -b foo' a shortcut for 'branch foo;
commit'?  It's a tiny shortcut for a rare action.

BTW, 'branch' also helps make the mental model of the "workspace" more
consistent.  A workspace is the place you set up all the properties of
a revision-to-be; most obviously this includes the contents of the
files in that revision, but a revision's branch is just as interesting
a property as its manifest, and it makes perfect sense to set up both
(and potentially other things), check that 'mtn status' looks like
what you want, and then hit 'commit' to set it in stone.

> I'm just suggesting trying to make smallish changes that would make
> things that seem natural in (say) subversion equally natural in
> monotone.
> 
> One of those seems to me to be creating a branch, then starting work
> on it.  I've not used subversion much, but coming from other systems,
> this difference in monotone feels just a little awkward.  
> 
> Underneath the implementation's not quite the same (in that the branch
> won't actually exist in any database until I commit something to it),
> but that seems OK.

This is a feature, not a bug :-).  It's _good_ that you have that
designated time (when you hit 'commit') to look things over, make sure
that it's what you expect...

> (I haven't been paying attention to what "mtn branch" is supposed to
> do.  I'm just dubious that it's worth making it do anything except
> make a new branch and change the workspace to that.  But then I'm
> dubious about the value of "clone", and I guess there's a reasonable
> case for that (given that it'll more or less match the similarly named
> commant in other systems).)

Eh, I at least would argue that the goal is not to match other systems
-- it's a factor, but only one of many, and not particularly high on
the list.  The argument for clone is the same argument we hope applies
to any UI change -- it makes life easier :-).  Just try telling
someone "Oh, you want to get the latest source?  Okay, check this web
page where I've written down the whole list of commands to do that,
it's a little too complicated to explain on IRC...", the appeal of a
single-command version will probably become obvious :-).

-- Nathaniel

-- 
Damn the Solar System.  Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
  -- Lord Jeffrey