As Matt (the author of the Mercurial plugin for Jira) pointed out in his comment, there was an issue with the permissions for the plugin. Seemingly random people were able to see the Mercurial Commits tab, and all along I thought I messed something up when I ported the plugin from Jira 3.6.2 to Jira 3.6.5 and then to Jira 3.7. (Yes, I know Jira 3.8 is out, we didn’t schedule the migration yet).
Lately I’ve been busy closing bugs in Conary land, and haven’t got the time to go back and investigate what’s going on. Last week I finally decided I should look at the code – and it became very obvious. There is a View Version Control permission that controls who can see what, and it turned out only several groups were granted that permission. We’ve only allowed access to commits to internal users for now, but that may change in the future.
Also, yesterday I noticed that Jira was not indexing the Mercurial repositories anymore. As usual, catalina.out is full of useless messages, so reading the code again pointed out that I got the configuration wrong. Funny it did work at all. Turns out hg.clonedir.idx is indeed supposed to be the top directory where your Mercurial clones are, and not the directory where you cloned the repository. That is derived from the URL. Doh!
I don’t know much about murcurial, other than I checked out the opensolaris kernel with it the other day. It seems like just one more in a long list of ‘decentralized’ scm software. Is there any reason it might be better than, say, subversion or git?
It compares more to git than to subversion. It is decentralized. In a way, it breaks the concept of branches, because it doesn’t natively support them, but you achieve exactly the same functionality with multiple clones (and works much better too).
For instance, to implement “vendor branches” the way CVS describes them (i.e. a branch where I import upstream projects and I periodically merge them back into my HEAD branch), all I generally do is:
- download project from upstream (as project–upstream)
- hg init in that directory
- hg clone project–upstream project–devel
Now I do all my work in project–devel. Periodically I will refresh project–upstream from the released tarballs. When I am ready, I can just go into project–devel and do hg pull – this will merge all the upstream changes into my devel copy.
Extra points if upstream is Mercurial, of course. If it’s subversion, I probably could do a better job and import individual changesets (something tailor does).
One area mercurial helps me quite a bit is synchronize my personal documents. I have copies lying around on my home system, laptop and work system (for convenience). If I make a change I don’t have to do rsync and worry which one is the latest and is it safe to rsync in that directory, or I’ll overwrite something. Mercurial does the versioning for me. If I modified in both places, I just merge the trees and move on.