Monotone analysis

[Felipe Contreras]

On Fri, Jul 11, 2008 at 1:50 AM, Gary Kramlich <grim at reaperworld.com> wrote:
>> Hi Gary,
>
> This will be my last response since this thread has gone on far too long
> and I have other things I *NEED* to be doing.
>
> <snip>
>
>>> 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 mutati=
> on.
>>=20
>> That depends on your definition of history. Is history only the
>> commits that make it into mtn? Is history only the commits that get
>> pulled into the repository of one of the maintainers?
>
> As I was alluding to in my previous post, is that for us, the history is
> what *IS* _IN_ the monotone db.  By your logic, code snipets in irc, or
> ims, or what have you are considered history, and as far as I know, no
> tool handles that.

Which mtn database? You've said yourself that temporary branches are
possible, you just don't push them, are those part of the history?
What if I created a patch series from tmp_branch_1, and then after a
review fixed them in tmp_branch_2, both are in a mtn db, but I'm
sending patches instead of pushing the branches. The commits are there
in a mtn db, do they constitute 'history'?

Changes are changes; whether they are committed in a maintainer mtn
db, in a temporal mtn branch, in patches in the tracker, the mailing
list and code snipets in the irc.

> <snip>
>
>> No, rebasing happens in mtn too, when you review patches and ask for
>> changes, the patch should apply into a head, right?. The only
>> difference is that git provides tools for doing that, while with mtn
>> you are on your own.
>
> See above.
>
> <snip>
>
>> Do you always apply patches exactly are they are sent to you? If you
>> do some changes then you are mutating the history, at least according
>> to some definition of 'history'.
>
> I personally will take a contributors patch, commit it with an author
> cert with their name, and then proceed to do any adjustments with my
> normal author cert.  This is not only important to make sure that the
> correct credit/blame is given, but is also important if there is concern
> about the code from a contributor (ie, who has copyright over it, who
> needs to be contacted in case of license change, etc).

Fair enough, but not everyone does that. Most of my patches are modified.

> <snip>
>
>>> Why is not being able to rebase unhelpful?
>>=20
>> It's helpful, but it's much more helpful to rebase it.
>>=20
>> With git-rebase you can do more than just rebase. If you do a commit
>> a, and later on you realize that you screwed up, so you do a fix
>> commit a, later on you can do "git rebase --interactive" and squash
>> the two commits into one, you can reorder your commits, edit them,
>> drop them, etc.
>>=20
>> I can hear you saying again "we don't want mutable history".
>>=20
>> Let's do a thought experiment. You have the real repo in A, and you
>> have a utility repo in B. In A you have non-mutable history, just like
>> in mtn, in B you have mutable history. You have a temporal branch on
>> B, which you rebase constantly squash commits, re-edit them, reorder,
>> etc.
>>=20
>> Once you are happy with the commits you would want them into repo A,
>> but if you really think B is tainted since it has mutable history,
>> then you use git to create patches, and you email those patches to
>> yourself, and then you download those patches, and apply them into
>> repo A.
>>=20
>> Applying patches is not mutating history, right? So git-rebase can be
>> used with repos that don't have mutable history.
>
> Don't take this personally, but you're entire example sounds like busy
> work.  If you're revision is trash, you disapprove it with mtn
> disapprove.  This causes divergence, which to me, and I believe the
> other pidgin developers, is exactly what we want.  With that divergence,
> you have two heads, you then merge them, and essentially squash it.  The
> only difference that I see, is that monotone keeps this history around,
> and you can't reorder the commits.  Both of which I find extremely useful=
> =2E

You missed the point; what you are applying in repo A are patches. A
patch series can re reorderd, merged, droped, right?

Or suddenly the origin of the patches makes them constitute 'history'
and therefore should not be reorderd, merged or dropped?

> <snip>
>
>>> So you want to "hide" the history?
>>=20
>> What history? You merged branch "foo" into master, if you remove
>> "foo", all the commits would still be there, the merge would still be
>> there, even the name of the branch would still be there because by
>> default the message of a merge is 'merged foo'.
>>=20
>> So what is missing? A pointer to "foo" right? But if you are not going
>> to use "foo" anymore what's the point of having it? No history is
>> lost, you can even create the pointer later on if you miss it so much.
>
> I guess I'm confused here... Since you're "remove" doesn't appear to
> actually remove anything.  Aside for that, I believe theres a difference
> in terminology here.  In monotone you propagate revs from one branch to
> another.  When you propagate, the branch is left working in the event
> you want to continue to use it.  When you're done with it, you suspend
> the branch, saying that no further development should happen on this
> branch.  When a branch is suspended, it is hidden from mtn ls branches
> and the automate commands, unless suspended branches are explicitly
> requested.

A branch in git is merely a pointer.

When you remove a branch you remove the pointer, not the commits in the branch.

You can consider a removed branch a suspended branch, it's hidden. If
you want to resume work on that branch you can create a new one, with
the same name, pointing to the same commit, so it's exactly the same
branch.

> This is usefully for many reasons.  Say you're working on a major API
> rewrite and have finished a portion of it, and think that it's stable
> and complete enough for further testing.  At that point, you propagate
> it to im.pidgin.pidgin (or master in git terms) for further testing.
> However, since theres going to be a lot more breakage, you continue to
> work on it off of the main branch until you're ready repeat the cycle
> until the rewrite is complete.

I believe what you call propagate is simply a merge. In git there's no
distinction between merging and propagating, it's called merge. If you
continue to work on it or not it doesn't matter.

> <snip>
>
>> Actually none of the projects I participate in use git, I'm perfectly
>> fine with svn/cvs/bzr. The only tool I can't stand is mtn.
>
> This is find, it's you're prerogative to use/like any tool you choose.
> However, we like monotone, and see no benefits on switching at this time
> that outweigh updating all of our tools/scripts/trac/etc as well as
> having to learn a new SCM.

Right.

>>> But that wouldn't be right either.  At any rate, I get it.  You have a=
> n
>>> 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?
>>=20
>> Yeah, tailor is crappy. It will create a single branch out of the mtn
>> tree and convert it to git. Just like mtn->svn->git. And even with
>> crappy messages like: [foo-migrate @ whatever].
>>=20
>> In case you didn't notice I created a tool that converts a mtn repo
>> into a git repo, preserving all the history:
>> http://pidgin.im/pipermail/devel/2008-June/006125.html
>
> Seems to me, that a lot more people would have benefited if the flaw in
> tailor had been corrected instead of creating yet another tool, that
> will probably bit rot due to the authors hatred for monotone.

I saw the code in tailor, and I tried to improve it, however the
design is flawed. Trying to make it replicate the exact topology would
require to make it tailor2; a completely different tool. Also, it
doesn't even work for the simplistic use-case that it's supposedly
supporting right now, at least with git.

Besides, there's no reason for such a tool, there are much more
effective tools to communicate between git-bzr, git-svn, bzr-git,
bzr-svn, git-cvs and bzr-cvs. I don't see the point of tailor.

> <snip>
>
>>>> I was talking about John Bailey.
>>> So you're trying to make a technical discussion personal, interesting.=
> =2E.
>>=20
>> No. he seems to take this personally, I was just pointing that out.
>
> And pointing it out for what reason?  The only one I can come up with is
> that you're looking to either discredit him, humiliate him public, or
> something else that I can't come up with.

Surely it wasn't to suggest to don't take it personally, that would be
too sensible for me.

> What I find really funny here, is that both John and myself have *TRIED*
> to make things easier for you to work with Pidgin.  John even went as
> far as providing svn mirror of our monotone repository and from what you
> said above, should have been more than adequate.  Now I haven't looked
> at the logs yet, but I'm willing to bet that it'll show minor usage if an=
> y.

Perhaps if it was actually announced in the mailing list or with a
link on devel.pidgin.im. I still believe it's useful for people that
want to contribute patches.

> The point I'm getting to here, is that if anyone has a right to be
> pissed at you, it is John.  Creating and maintaining a mirror has a very
> expensive startup cost.  I also know that John tried to setup a git
> mirror of our monotone as well.  And what does he get for it, more
> bullshit from you and personal attacks.  But that's okay, because I'm
> sure he had nothing better to do...

Which personal attacks? I'm grateful for your support and John's, does
that means I can't criticize monotone?

Again, if I think mtn sucks that has nothing to do with you, or John.

>> Cheers.
>
> As I said, this is the last you'll hear from me on this topic.
> Personally, I find the whole thing quite stupid and can't believe I've
> wasted this much time trying to reach a calm consensus when I should
> have been doing more important things like writing code and mentoring my
> summer of code student.

Suit yourself, I would have liked for you to understand that rebasing
doesn't alter a non-mutable history in exactly the same sense as quilt
doesn't.

Personally I hope at least some people have learned a thing or two in
this discussion, even if they remained silent.

Best regards.

-- 
Felipe Contreras