In message <[EMAIL PROTECTED]> on Fri, 23 Feb 2007 16:14:03 +1100, William Uther <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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 _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
