Most of my work is for the OpenEmbedded project and they use monotone.
Please add monotone support!
Yes, please, monotone support.
Hi, OE folks, I'd love to see mtn support too. Alternatively - git in OE ;-) (or OE in git?)
Just another voice for monotone support.
monotone support would be awesome, what can i do to help?
Some months ago someone of the Ohloh staff said they were thinking about opensourcing that part of the probject. I wonder =)
All I see is ohcount which isn't helpful for when it comes to adding additional SCM's :)
+1 for monotone support
Why monotone support?
OE is already switching to git.
Felipe, look at the dates ;-) But OE is not the only project using mtn. There's also pidgin...
And seeing as I'm a pidgin developer, monotone support would be nice. We also use it for guifications and the pluginpack as well...
Michael, Felips is well aware that we use monotone, he's following Linus's orders to convert everyone after Linus read an email/blog of one of the Pidgin developers without actually reading it in detail.
Well, grim, I was skeptical about git once it came to life (yes, I thought whatever Linus makes will be praised regardless of merits), but to tell you the truth, now if I were you, I'd want pidgin to move to git instead, like I wanted it for OE, being an OE developer.
That said, I still think supporting mtn is a good thing, even if majority doesn't use it. After all, I hate majority even when I belong to it ;-)
grim: I'm not converting anyone, that's the natural flow of things; superior things win.
In any case, I was wondering if there were other projects that use monotone. So far it seems that it's not worth the trouble.
Michael: how did you convert your mtn repo to git?
It would be good if they open enough of their repository analyzing stuff, and then some mtn user implements that support. But otherwise I don't see why they should spend time doing it.
Felipe: I'm not sure, one of the OE developers created a converter in python. Before he did (or better - before he finished, that was almost a year ago, anyway), I've started to write a two-way git-mtn gateway (akin to git-svn) in c++, but never finished it due to the lack of time, it did the mtn to git conversion, though. There's also this 'tailor' anything-to-anything converter, but last time I checked it didn't work quite well for the purpose.
And it's entirely wrong point that superior should win. I mean, there are many things that are natural and not following the nature is what makes human.
And I think they should support mtn just for the sake of completeness. I doubt they will, though.
Felipe, oh I'm sorry, then what was the point of your email to the pidgin devel list about OE switching? And if you would read, I've already asked IN THIS THREAD what I can do to help get mtn support done.
To show that the scarce mtn userbase is evaporating?
Meh, we don't really care... I know you're going to have a hard time understanding this, so bear with me... WE ARE HAPPY WITH MONOTONE we see no reason to switch at this time that justifies the expense in learning a new tool, taking the time to convert the history, restructure infastructure and so on
As another Pidgin developer, I too would love to see monotone supported here.
grim: the fact that you (core developers) don't care that your contributors need to install/learn yet another SCM (which is each time more obscure) is your fault; lack of empathy is not a virtue.
In any case, there's more people in the ml than just core developers.
I personally must admit that the "wrong" choice of SCM on developers part sometimes prevents me from contributing, but that's about freedom - core developers have one of choice here.
You seem to have problems with people holding different opinion...
And if you really want to solve the problem without introducing new ones, then instead of forcing your opinion upon others do develop git-mtn two-way bridge.
I'm not forcing my opinion, I just explained my arguments. Pidgin core developers are free to keep using mtn, and I'm free to argue that's not the best choice.
One of the reasons I didn't try to do a git-mtn two-way bridge is because I was denied access. So I did a mtn->git converter and I sent my changes as patches.
Now that I've left the project I see no reason for a git-mtn bridge, just for this project.
Felipe: to an innocent bystander like me (not a pidgin developer nor even user), you certainly seem to try and force your opinion on others. Calling mtn "not the best choice" is an indication of that.
Now I personally like using mtn (after having evaluated cvs, svn, svk, git, bazaar, mercurial, several arch-derivates and an obscure one I forgot the name of), so I'm biased in that respect... but I wouldn't go and call git "not the best choice" - it wouldn't be for me, but it might very well be for other people.
Just let it rest. The pidgin developers posting here seem content.
Yes, Felipe, of course you are free to.
Although, your last sentence suggests that in addition to the right you want a reason, and I can't think of what makes you reiterate your opinion over and over now that you've left the project ;-)
Jens: I wouldn't say bzr, hg or even darcs are "not the best choice" because I don't know enough about them. I know a bit of bzr and if some people might prefer bzr over git, I think it's ok, a matter of personal taste.
But I do know enough of mtn, at least in the way Pidgin devs use it, and I have a strong opinion that it's not the right choice; it's my opinion, and I was simply saying that I have the right to state it. On the other hand you might be using it differently and it might make sense for you, I'm not arguing it's not the best choice for you.
I already explained that my purpose was to find out if more projects were using mtn. Because as I already said, I see mtn as disappearing, and I'm interested in finding out evidence of the contrary.
It was grim the one brought out that stuff on the pidgin ml that wasn't appropriate for this thread. I saw that as an ad-hominem attack and I just felt compelled to defend my opinion.