[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Command design and naming?
From: |
William Uther |
Subject: |
Re: [Monotone-devel] Command design and naming? |
Date: |
Sat, 24 Feb 2007 07:14:31 +1100 |
On 24/02/2007, at 2:02 AM, Richard Levitte - VMS Whacker wrote:
A small amount of syntactic sugar can have big consequences. It has
to be maintained over time, and it could lead to as much confusion as
it can help (see tla and the pletora of subcommands that do almost,
but not quite the same thing). Sort of "Oh shit, I shouldn't have
done it *that* way this time!" kind of confusion.
Yes, it is important to design things well. Hence my email :).
willu> This is a side issue, but no I'm not amazingly bent on specific
willu> branches. I had simply noted that if you commit in one branch,
willu> you don't expect your work in another branch to be synced.
... unless you're working in several branches at once, for example
when a change in one requires a change that belongs in another that is
then propagated to the first. I've worked a lot that way, even before
I started using monotone.
In which case you could always sync manually? Is it going to beak
anything horribly if you have been working as you suggest and only
sync that branch? You can still sync afterwards, right?
Oh goody good! Code is a good way to make a case. Actually, nothing
stops you from creating a branch for yourself where you develop that.
Hehe. Well, I originally intended to make my own branch. So I
checked out a new wc:
% mtn -d mt.db -b net.venge.monotone monotone-newcmds
Then I went to put it on a branch:
% cd monotone-newcmds
% mtn ci -b net.venge.monotone.new-commands -m "start a branch for
new commands"
mtn: misuse: no changes to commit
I'm not sure how I feel about that. I can see why the check is
there, and I'm guessing there are two ways around it:
i) make some changes first :)
ii) create some new cert so that the old revision is on both the old
and new branches, then update the wc to the new branch.
I figured i) was easier.
willu> From the tone of your email I suspect that my email volume is
willu> annoying you.
No. But you may want to know that I can come out pretty powerfully
and arrogantly when I've an opinion I stand by. You're not the first
to have mistaken that for being annoyed ;).
Well, ok, perhaps not entirely true. I do get annoyed when people
wanna try something new without trying to read up and understand the
new thing, and are instead expecting it to behave like their old
thing. And no, I don't see you as such a person, but it seems like
you have some sort of pressure from people who seem to do just that,
not read up.
Yes. If mtn can accommodate them easily, then it might win more
converts. Of course, that might be a bad thing - you'll get more
bozos posting on mailing lists. :p
So my appologies, I understand that you may be caught
between a rock and a hard place. I'll see if I can get a bit less
aggressive ;).
It's ok, I'm tough. I just didn't want my first move in a new place
to be to piss off the people who I'll want to commit my patches :).
willu> Having said that, Monotone is a very nice VCS, but it hits
willu> people transferring from other systems with a fair few gotchas.
Oh yeah, there are gotchas, I agree with that. Those I see are the
amount of time the initial pull of a large project can take and that
the security system is a bit weak. As far as I know, both are being
worked on (the latter in the form of policy branches, something I
really look forward to trying out (*wink* *wink* *nudge* *nudge*)).
I think partial pull is more of an issue for new users than
security. The security model of mtn is at least as good as that of cvs.
I understand that one of your gotchas is verbosity (interestingly
enough, since you see yourself as quite verbose ;)) and lack of
support for a centralised view. Anything else?
The verbosity is more an input verbosity than an output verbosity
thing. The commands are at a lower level of abstraction than they
could be (or rather, you could do with higher level commands in
addition to the current ones).
I'm making sure I list my itches: http://venge.net/mtn-wiki/WishList
They're not in any particular order. Many of them are being worked on.
Bah, I'm sure you have more to give. Welcome to this community!
Thanks :)
Will :-}
- Re: [Monotone-devel] Command design and naming?, (continued)
- Re: [Monotone-devel] Command design and naming?, Thomas Keller, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, hendrik, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, Alex Queiroz, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, hendrik, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, Richard Levitte - VMS Whacker, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, hendrik, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, William Uther, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, Richard Levitte - VMS Whacker, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, hendrik, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, Richard Levitte - VMS Whacker, 2007/02/23
- Re: [Monotone-devel] Command design and naming?,
William Uther <=
- Re: [Monotone-devel] Command design and naming?, Richard Levitte - VMS Whacker, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, William Uther, 2007/02/23
Re: [Monotone-devel] Command design and naming?, Thomas Moschny, 2007/02/23