monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Command design and naming?


From: Richard Levitte - VMS Whacker
Subject: Re: [Monotone-devel] Command design and naming?
Date: Fri, 23 Feb 2007 08:56:24 +0100 (CET)

In message <address@hidden> on Fri, 23 Feb 2007 16:14:03 +1100, William Uther 
<address@hidden> said:

willus>    In my copious free time I'm going to start hacking on
willus> monotone.  The itches I wanted to scratch involve making it
willus> easy to use for people who are used to CVS or Subversion (see
willus> http://venge.net/mtn-wiki/WishList ).  In particular, I want
willus> to introduce three commands that:
willus> 
willus> A: For checkout:  mtn pull branch && mtn checkout
willus> B: For commit:    mtn commit && mtn pull branch && mtn merge && mtn  
willus> push branch
willus> C: For update:    mtn pull branch && mtn merge && mtn update

I'm noticing that you're very bent on specific branches, when the
argument to pull is a pattern and represents a set of branches, not
just one.  I know that that you initially think that you only need
that particular branch, but then someone is branching from that
branch, and you wanna follow that as well, and so on.

willus> Option _i_.  Rename commit to local-commit, or lci.  Rename
willus> update to local-update, or lup.  Then use 'commit' for B and
willus> 'update' for C.
willus> 
willus> Option _ii_.  Use 'remote-commit', or rci, for B and use
willus> 'remote-update', or rup, for C.

Option i would be a grave mistake, in my opinion, for two reasons:

 - years of having monotone work the way it does, and that way being
   very well designed (in my opinion).
 - To change it to be a CVS lookalike would break the elegance of the
   design, and reduce its power, psychologically and philosophically.

Since you're thinking of those commands as some super-charged thingy,
can I suggest "super"?

        mtn super checkout
        mtn super commit
        mtn super update

Alternatively, since this is derived from the CVS way, I suggest
making a script called 'mtn-cvs':

        mtn-cvs checkout
        mtn-cvs commit
        mtn-cvs update

Or actually, you could also simply make a script called 'cvs' that
acts as a wrapper!

willus> Or, have current commands change name which is a change for
willus> current users, but easier for switchers from other VCSs
willus> (Option i).

Quite honestly, I disagree.  It took me about 10 minutes to read and
understand that you do your work against a local repository, then
transfer changes back and forth between your local repository and a
remote one.  It took me a blink of an eye to see the elegance with
having a local copy of the history of what I was working on.  All you
have to do is read the manual (not the man page, which has recently
been removed).
Before working with monotone, I was heavy on CVS and had tried at
least half a dozen other VCS' and rejected them all, some because 
they tried to emulate CVS too well.

I'm skipping everything about option ii, since you said yourself that
it was overkill, and I agree.

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis




reply via email to

[Prev in Thread] Current Thread [Next in Thread]