Monotone analysis

[Felipe Contreras]

Hi,

Regarding the multiple "mutable history is not an option for us".

I sent a couple of patches, and I received some comments, so I was
expected to modify the patches, isn't that mutating the history?
Imagine the patches where in my mtn repository, and somehow I'm able
to fix them, and send them again. The maintainers shouldn't care about
how the patches where created, just that they are ok.

So mutable history is not an option for maintainers, but it is the
only option for contributors without commit access, at least when
there's reviewing and changes needed.

Quoting Linus [1]:
"a grunt should use 'git rebase' to keep his own work in line. A
technical manager, while he hopefully does some useful work on his
own, should strive to make _others_ do as much work as possible, and
then 'git rebase' is the wrong thing, because it will always make it
harder for the people around you to track your tree and to help you
update your tree."

On Thu, Jul 10, 2008 at 3:32 AM, Gary Kramlich <grim at reaperworld.com> wrote:
> Felipe Contreras wrote:
>> On Thu, Jul 10, 2008 at 2:34 AM, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
>>> On Thu, Jul 10, 2008 at 02:02:16AM +0300, Felipe Contreras wrote:
>>>> 2008/7/9 John Bailey <rekkanoryo at rekkanoryo.org>:
>>>> You can achieve with temporal/topic/local branches what you can
>>>> achieve with microbranches, except that you have control over what's
>>>> happening.
>>> I can control what happens in a microbranch just as well as any git,
>>> bzr, or hg user can with their branches.
>>
>> You can't decide to drop a commit that somebody else already did, like
>> an applied patch.
>
> mutable history isn't an option for us
>
>> You can't cleanup the commits somebody else did in his branch before
>> integrating it into your branch.
>
> mutable history isn't an option for us
>
>> You can't cherry pick commits from a remote branch.
>
> mtn help pluck

That's from the same repository.

>> In mtn is all or nothing.
>
> in mtn we read all the documentation

I was arguing that you don't have control over what happens.

>>>> Git/bzr/hg provide better tools to manage the divergence: cheap branches.
>>> And monotone branches aren't cheap?  Seriously, what are you smoking?
>>
>> I have 18 branches in msn-pecan. 12 local and 6 remote. I can
>> reorganize the commits as much as I want locally, move the commits
>> from one branch to another, and then push to the remote branches,
>> nobody has to notice I have local branches. When I'm done I can remove
>> both the local and the remote branches.
>
> mtn approve -rDEADBEEF -b im.pidgin.someother branch
>
> Look i just copied a commit to another branch.  As far as moving goes,
> mutable history isn't an option for us.
>
> Local branches are possible in mtn as well, you never push them.  When
> you want to move all your commits from a local branch to a "remote"
> branch, propagate and push the remote branch.

Sure, but a local branch that you can't rebase isn't that helpful.

>> Adding and removing branches is cheap because a branch is simply a
>> reference to a commit. Creating a branch is creating a one line file,
>> and removing the file removes the branch.
>
> A branch is just a cert.  When it comes to removing branches, mutable
> history is not an option for us.
>
>> In mtn, creating a branch means to add a cert to each and every commit
>> in the branch, while that is not too bad once created, you can't
>> remove it. So you must be careful when you create a branch; it's not
>> cheap.
>
> mutable history isn't an option for us.  We *WANT* to know about the
> branch even if it's not used anymore.

All the commits of the branch are still there, it's just the pointer
that disappears. You would see it as a microbranch merge.

It's not mutable history.

>>>> Of course MTN isn't hard to use once you get used to it, CVS wasn't
>>>> either, but once you get used to something superior, you can't go back
>>>> to the madnes. Would you do serious development in CVS again? Even if
>>>> a project you want to contribute to is using it and they see no reason
>>>> to change?
>>> Yes, I would.  CVS may suck, but it does what it does in a predictable
>>> and well-known fashion.  I do, in fact, still use CVS on occasion.
>>
>> on occasion != serious development.
>
> On occasion can be, damn this app I use every day is consistently
> crashing, I need to fix it.  Which to me, is serious development.

s/serious development/constant contribution/

>>>> There's a reason why nobody is using mtn: it's not ok.
>>> And again you spout an _opinion_ that you haven't supported with any
>>> real, irrefutable evidence.  If you want to bitch about monotone, go
>>> bitch to its developers.  I'm tired of seeing your complaints about our
>>> decision on what tool to use.  If you can't handle that, tough.
>>
>> I would like to hear another theory about why nobody is using it.
>
> How's this?  People think Linus knows best in every situation?

That doesn't even make sense. Bazaar is quite popular too and git
isn't even maintained by Linus, people disagree with Linus on the git
mailing list too. And there's also mercurial. Those are used.

>> Fortunately I don't have to work with such a horrid tool where it's
>> impossible to follow what's happening on a single branch without a
>> diagram, let alone the whole project.
>
> care to elaborate?

I don't have to work with mtn.

In other tools you see: merged silly_fix. In mtn you would have to
open a visualization tool just to see what the hell that merge
239247130283 into 85938403482 meant.

>> And by the way, I don't see why you react so passionately about
>> criticism to the DSCM you are using. It's just a tool, tools can suck.
>
> Passionately... hmm, I thought we were reacting rationally, I'll be sure
> not to make that mistake again.

I was talking about John Bailey.

Best regards.

[1] http://kerneltrap.org/Linux/Git_Management

-- 
Felipe Contreras