Monotone analysis

[Gary Kramlich]

Felipe Contreras wrote:
> 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.

If the patch was provided as a pull from your database that you served
via mtn serve for us to grab the revs then yes, there wouldn't be any
mutating of history.  Since your patch was never in mtn which is the
location of the history that shouldn't be mutated, there was no mutation.

> 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.

See above

> 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."

So where do we fall?  Are we the grunts or you?  Either way doesn't
matter, we're all least attempting to do work.  The amount of work
should not determine which workflows should be used.  To me, it sounds
like git-rebase was added to shut people up that spaz out when theres
too much divergance in the history, and make it look more like a CSCM.

<snip>

>>> You can't cherry pick commits from a remote branch.
>> mtn help pluck
> 
> That's from the same repository.

Not if you pull the remote branch in, which is how it's supposed to be
done in monotone.

>>> 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.

To clean up commits made by someone else, would be mutating the history.
 Which as I'm sure you know by now, that is not something we want.

<snip>

>> 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.

Why is not being able to rebase unhelpful?

<snip>

>> 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.

So you want to "hide" the history?

<snip>

>> 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/

I still disagree.  On another project I'm working, we're using svn.  I
absolutely despise svn, possibly more so than you do mtn (if that's
possible).  But we're using svn, because it's what everyone else knows
and understands.  The level of support I don't have to provide more than
makes up for having to use what I find a obsolete tool.

>>>>> 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.

For the record, that was tongue in cheek.  The point I was alluding to,
is that I can't believe you're going around telling every project that's
not using git to go and use git, or even every project that's using
monotone to go and switch to git.

But that wouldn't be right either.  At any rate, I get it.  You have an
itch to scratch, you want to work on msn, you don't like mtn.  That's
fine, luckily plugins can easily be developed out of tree.  Or if that's
not an option use tailor to export our mtn to git, and if need be, git
back to mtn.  Or is tailor just another crappy tool?

<snip>

> I don't have to work with mtn.

see above

> 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.

Right, and when you open said visualization tool, it'll load up
everything just once, and look, you have all your history there that
saves you're precious 8.5 seconds more that it took to do an mtn merge.

<snip>

> I was talking about John Bailey.

So you're trying to make a technical discussion personal, interesting...

> Best regards.

-- 
Gary Kramlich <grim at reaperworld.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20080709/0c3aee5a/attachment.sig>