Support for Monotone

Felipe, please don't take this personally... (gl to me on that...), but I really don't think you fully comprehend how pidgin developers use monotone. As such, I've gone through the trouble of creating a massive flow chart explaining how I use monotone. And I use monotone for everything I work on now (that I control).

Anyways, please READ this entry from my blog

grim: if you don't want me to take things personal then why do you add that (gl to me on that)?

Anyway, I don't take it personal, I already know that you think I don't get how you work with monotone.

What makes you think that? Surely you must have an example of something I'm not getting.

BTW you are missing a 'no' arrow from 'Is the branch already checked out?' and the 'yes' arrow is missing the caption.

Also, if you go through 'Change to the checked out directory' you don't need to go through 'check-out', right?

Another vote here to add monotone support to Ohloh :)

Whoops, the flowchart has been updated.

Anyways, apparently theres something I'm not getting. Because as you can see form the flow chart, I normally use 8 commands for mtn, nothing major, nothing cryptic.

Yet time and time again, I've seen, "oh use -s to use an existing db", "compress the object cache (or whatever it is) with whatever", do this with that and so on.

Now, it may just be me, but you shouldn't need to know all these little cryptic arguments or numerous commands to manage your code.

Sure monotone may be slower, it may not have a lot of users, but you know what, It doesn't get in my way, it doesn't cause me to remember which out of 130* commands I need to know, it's fairly intuitive, it gets the job done, and let's me do what I need to do. This is bar far the most important thing to me.

• based off of "$ ls /usr/bin/git-* | wc -l"

grim: you can remove all of those git-* if you want.

I've added comments to your diagram to show how your workflow would look like in git: link

If i want to break my package manager or mess with dpkg-divert or whatever it is.

Anyways, what's going on here? I took 6 different actions I perform on a normal basis and mapped whats involved. You're updates aren't exactly clear, some are pointing what you do in git and others are just there.

So all the branches are always in the database (those that are served on the remote end, I know there are local branches, I'm not talking about those). So if someone is working in a branch that I don't care about until it's merged, I have to pull the revs in git. This is not necessary in mtn.

As you point out, use the db is in the same directory as the working copy, and yes you can use that database in another working copy. What if i want to kill the working copy that has the database? Or is the database hardlinked into the other wc if i use "git clone -s" or whatever it is?

Also, mtn propagate is a simplified form of explicit _ merge. It merges two heads, that is the distinction and normally what you want to do. However, when theres LOTS of divergence, like say there hasn't been a merge months and theres been a ton of activity. You can use explicit _ merge to make it easier, but breaking up giant divergence to more manageable divergence.

The "only one head per branch" is a difference in implementation. Monotone knows that it will not always solve divergence, and thus embraces it. It is *my* understanding that git forces a lack of divergence by making the developer handle it. But I really have no idea because I haven't ran into divergence with git.

Usher is a concentrator for mtn serve. If you don't use it, you have to pick different ports for each database you want to serve. Think of the old UNIX mantra, "do one thing, and do it well", that's where usher fits in.

Approve is a cert, nothing more. I know you've seen some of the cert system, but I think you missed the point of the approve here. When you do mtn approve -b ${branch name}, monotone will commit a new revision with a branch cert that has a value of the new branch. That is how you branch in monotone. However, you can use mtn approve with no *-b ${branch name}" to sign off on a revision. This can be used for code reviews/signoffs, test results, whatever else you can dream up.

As I mentioned earlier, you don't really explain how to perform these six actions in git. For example, how do you create a new branch from an existing one, how do I work on a new (to me branch) in a new working copy, how do I create a new branch that is completely unrelated to any existing branch, etc.

(note, had to edit this a few times due to the markup messing up the output...)

grim: actually I forgot to add two actions, those are not exactly easy to map into your diagram.

This is more clear: link

Pulling revs is not expensive in git, so if something is really not interesting for some people it should be put in a different repo. Probably there's a way to only fetch certain branches too, but who cares.

Each working directory has the whole repository, and it's hardlinked by default. So it doesn't take space, and nothing bad happens when you remove the original one. However, you have other options, like a shared repo, and a bare clone, combining those two you can achieve the same as with mtn's db.

A merge is a merge in git.

git "embraces" the divergence even better, because each of the possible 'second head' commits has a name. So it's easy to see what's happening. For example you can see what is the diff between your head, and the one in the main repo with 'git diff origin/master master', or you can do an 'explicit merge' with 'git merge origin/master'.

There's no need for usher in git, multiple repos are as natural as directories in ftp.

Aha, so if I understand correctly the branch is not created until after you do that 'mtn approve', that means it will only put the last commit in the new branch. So that means you shouldn't do any commits when you are 'Branching a branch' which in turn means you should skip the 'do some work' state.

That also means that 'start a new project/branch' is wrong because you are not creating the branch at any point.

In the new diagram these 6 actions should be pretty obvious. The only one I didn't add was 'serve a new project/branch' because that doesn't make sense in git; it's a simple 'git push ' but that's not what you would want to do, it depends on the kind of server you have.

Strike that 'explicit merge' with 'git merge origin/master', in git branches can be entangled, so a 'git pull' will do the 'explicit merge'.

That entanglement is configured by default when you create a local branch out of a remote branch, but you can remove that link, or create even more complex ones.

And there's still:

Is the branch already checked out? -> yes Change to the checked out directory, pull, Do the branches have multiple heads? -> no, checkout, <- huh?

Lovely, can't see your new image because the host is down for maintenance.

The location of the db is obviously, a personal choice. I like to know that I can easily pull out my db and back it up. Whether or not this is possible with git, is not my concern. However, hardlinks may save space, but unless tools know how to handle then, can confuse not only the tools but users as well. For example, I'm not sure if df knows how to handle hardlinks, but if it doesn't know how to handle them, the directories are going to look huge. However, this potential confusion is completely avoided in monotone since the db is it's own separate entity.

A merge is a merge in monotone as well. You merge two revisions. explicit _ merge just allows this, mtn merge will merge multiple heads on the same branch, and propagate, as I stated previously, merges all revs from once branch into another, using head on both branches.

Diffing between branches isn't embracing divergence... Anyways, its just as easy in monotone... mtn diff -r h:${branch name}. Of course you have to have the branch, but if you pulled with a wildcard and made it your default that isn't a problem.

Usher isn't necessary, you can drop all the projects you want in the world into a single mtn database. However, if the user chooses to use multiple db's to create a logical separation then it is. For example, on guifications.org, we have separate db's for our pidgin mirror, the plugin pack and gf2 and gf3 share a repo, misc.guificatoins.org has it's own, and so on.

When it comes to branching, the do some work before approve is optional. The approve does a ci, with a branch cert if you give it. The initial do_work that I do is usually something trivial, and just shows that the first rev on the branch is where I actually started working on the branch, rather than the second rev. As originally stated, this is how I use monotone.

No, the create a new project/branch is not wrong. When I say new branch, it could be completely unrelated to an existing. mtn -d ${dbname} setup -b ${branch name} sets up a working copy to be used. It updates ${topsrc_dir} to have a proper _MTN directory with all the info, including the branch name. When it's committed, the branch is created as well. Since in mtn, branches are just certs on revs. They're just another logical distinction. They don't change revs, they're just metadata associated with the revs.

grim: you can disable hardlinks, and you can of course backup the git 'database', it allows you to do things the mtn way if you so desire.

A merge is conceptually not just a merge in mtn, otherwise you wouldn't have done that distinction in your diagram.

And can you do a 'git diff upstream/master' and 'git diff subsystem/master', or 'git diff debian/master'?

Usher might not be necessary, but it is for your workflow, that's why you added it in your diagram.

So the 'mtn approve -b' is committing the changes you have in your working dir? weird.

Ah, I didn't notice the 'setup', I thought it was a 'co'. Maybe the label should explain that the branch is created at that point.

What about?

1. checked out? -> yes
2. Change to the checked out directory
3. pull
4. Do the branches have multiple heads? -> _no_
5. checkout <- huh?

Anyway, my point is that exactly the same workflow is much more easy in git.

Work on an existing branch: git checkout $branch

Branch a branch: git checkout -b $branch $orig_branch

Start a new project/branch: (project)git init, (branch)git checkout -b $branch

Work on a new project/branch: (project)git clone, (branch)git checkout -b $branch

Merging branches: git merge $branch

Serve a new project/branch: git push $uri $branch

Regardless of what was your original action you can always do git pull if you want to update from the original repo, do some work and git commit -a and publish your changes with git push.

I guess it's much more simple because you are always in a working directory.

BTW. Do you still think I don't get how you use mtn?

You may get how I use mtn, but a merge is a merge conceptually in monotone. However, how you want to merge is the distinction. merge happens in a branch, propagate merges two branches, and explicit merge merges two branches at the specified revs.

I'm not sure if you can do "git diff upstream/master" in monotone, because i have nfi what upstream/master is. It looks like a branch name, and if it is, yes you can do that.

Usher is necessary because i don't want to bottleneck on a single db for multiple projects since the db will be locked for all serving operations.

mtn approve -b doesn't need to even have changes, but if there are, it will use them.

You do a pull on the checked out directory to update the db to pull in all the revs. Remember divergence is expected in monotone, thus, a branch can have multiple heads when you pull it. If you pull it, you have two options, merge them, or update to one of the revs. But yeah, there should be an up in there... so yeah, 9 commands ;) Also, the flowchart has been updated for branch a branch with a dotted line at the start of the divergence (see it's natural, don't be afraid of it!! :P)

You can't say it's easier with the "workflows" you've given. To my knowledge, theres a lot of compress database, etc... Also having to be in a working directory isn't always a good thing ;). I can do most of this branch maintenance stuff without a working copy. Or hell I can do it on a box that's just serving the repos ;)

Anyways, the stuff like compress the database and so on, is the stuff, we, the pidgin developers missed when evaluating it back in the day. And we were using cogito, which as far as I know, died an ugly death. IIRC, at the time, the git command sucked, and thus cogito was written to make git "easier to work with". Somewhere in that time frame is when we picked monotone.

When you do a 'git clone' you get a remote repo called 'origin', and all the branches end up in 'origin/*'. However, you can add other remote repos, such as 'upstream', say the repo of your superior officer, and then all his branches are in 'upstream/*'. You can also specify which branches you want to see, but by default you get all of them.

So in git, branches are also distributed.

Now things are different, the repo is compressed automatically in certain operations. So the workflow I mentioned is the one you end up using; simple, easy, elegant.

What does "branches are also distributed" even mean?

And that may be the way things are now. But as I said, it's too expensive to change now for reasons all the pidgin developers and my self have attempted to explain before. Aside from that, I personally have put too much time into adding monotone support to other apps, namely jhbuild, and the reviewboard support is almost complete.

Nevermind about the distributed branches, it's not easy to explain.

Ok, so I hope you've already seen that the same workflow is simpler in git.

So the last argument is that it's too expensive to switch. It has already been explained in the mailing list, and I already refuted the argument.

You don't have to spend so much time with the transition, because for every tool you are using mtn there's already many people that did the same for git, and improved things to make it easier. So in many cases you don't have to do anything at all.

Now I hope you don't take it personally, but I see adding mtn support to other apps as a waste of time, at least for you. If you were using git you could forget about that entirely, or join many more people that are developing these tools, and collaborate.

What you seem to be missing is that I've ALREADY done the work. Thus I have more vested in monotone than the other pidgin developers.

Aside from that, theres nothing broken in monotone. It works for our (pidgin and guifications) purpose.

Aside from that, why would I move to a tool when it's original author has already called me an idiot when he himself didn't even read everything 1.

If you read more of that thread, Tso's response is dead on, but of course, it fell through the cracks. And while I hate to place blame, that thread wouldn't exist as it is, if you didn't keep pestering us about something we don't care about, which has led to many drawn out discussions, including this one.

I don't see he calling you an idiot anywhere. If you check the dates Linus read the post before the note was added, the note was added because of this thread in git's ml. And he is the original author, but not the maintainer, he is just one voice among many, Julio is the one that has the final word, not Linus.

In John's blog post he adds a note in the end, it is custom to strike your previous comment if it's not valid anymore, but apparently he didn't want to loose the mtn > git effect.

And BTW, this is the first time I read that stuff, so your original assumption was wrong, now I understand why you said that.

I don't see what is 'dead on' about Tso's response.

But anyway, you are saying that you already did the work, but that's with existing tools. Something new can come around, you would want support for mtn, and you would have to do it yourself. Not to mention virtually nobody is going to collaborate to improve mtn support, so you would probably would have to maintain that code.

Also, it doesn't matter if you are the best programmer in the world, an army of programmers would probably get better support for git, than you alone for mtn.

My note was not added as a result of the git mailing list discussion. It was added because I was approached in IRC and politely educated about my misunderstanding by someone who cared only for accuracy, and not zealotry.

I did not strike the git comparison because the point was not to edit the post. The point was to show that I don't know everything and say that it doesn't matter to me anyway.

The part of my post that no one cared to read--or if they did read it, they purposefully ignored it--is that of the 11 working copies I have, EIGHT of them are distinct branches. Everyone in that thread assumed they were just multiple copies of the same branch. I have the checkouts laying around for convenience. Switching branches in the same working copy is more of a pain in my ass than it's worth. The three checkouts that are duplicated are kept around as a reference point for when I make changes. It is useful (to me) to always have an unmodified tree on hand for comparisons when testing new code.

All that said, can we please drop this damn git crap already? This discussion is supposed to be about adding monotone support to Ohloh. It doesn't matter what any one person thinks about the popularity of monotone, and quite frankly I'm getting sick and tired of this git crap following us Pidgin developers wherever we go--we made our choice. If you don't like it, leave us alone.

You mean this guy? http://kerneltrap.org/mailarchive/git/2008/8/1/2775494

He started the discussion because he was misleaded by your post. He then learned that you were wrong, and then he approached you. It might not matter to you, but accuracy matters to the people that are reading what you write, so please strike that inaccurate information.

Your assumption is wrong. I don't think anybody thought you had 11 working directories with the same branch. What makes you think so?

Everyone there understood that the reason is convenience. That's why 'git clone' has options for that particular use-case.

Of course, most people don't do that because git has all the tools there so you don't have to do it, and I could explain you if you are interested, but I don't think you want to know.

Anyway, I'm a git supporter, and I will keep my position that it's a good choice for Pidgin, and probably for other mtn projects. So as long as you keep saying that it's not, specially with a bad understanding of git, I will keep showing you that you are wrong.

I'm all in favor of an amicable hands-on git evaluation, but that requires your cooperation.

If you want to cut the crap either accept that git is a good choice instead of mtn, or accept that you don't know enough about git to say it's not, or don't say anything.

I don't want to hear anything further about git from you because you've proven that you are nothing but a zealot who can't accept that your opinion doesn't matter to the powers that be. I am washing my hands of this discussion.

Calling me names doesn't change the facts. And you are not the "powers that be", other pidgin developers are interested in other SCMs.

Anyway, I also made the case for bzr, and hg as superior alternatives to mtn, am I also a zealot of those tools?

For the record, I offered you a dispassionate , educational, hands-on evaluation of git, but you don't want that because apparently, I'm just a zealot, which even if that where true shouldn't matter at all when presenting facts.

I haven't called you names, I haven't presented wrong facts, I really don't know why you have a grudge against me.

In any case, my offer for the amicable evaluation is still valid, but if you are not going to take it please don't post any more comments calling me names, or presenting wrong facts.

So what about monotone support?

+1 for Monotone (mtn) support, AuroraUX is using it. We actually switched from Mercurial (hg), Monotone is more of a solution.

There are very few projects using mtn, and now there's a git_export tool in the official mtn releases.

It's much easier for the few projects using mtn to just convert their repos to git, put the result somewhere and add that as an enlistment. You can update your mtn->git clone any time.

But of course the very fact that "mtn gitexport" exists would make importing monotone very easy for Ohloh developers as well (a simple script like "mtn pull ... ; mtn gitexport ..."), with the added benefit of using the official repository (and not a clone of it, which might be outdated) and point to the right direction with people looking at the enlistments for an address where to sync the repo from...