Monotone analysis

[Gary Kramlich]

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

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

<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

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

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.

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

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

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

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.

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

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

--=20
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/20080710/4bf9644d/attachment.sig>