Redmine

At least none of the main devs use bazaar, and you're as far as I can remember one of the 2 or 3 users I know of that use redmine and bazaar. Could you please checkout the bazaar repository used for the tests (rake test:scm:setup:bazaar in your redmine directory, the bazaar directory should then be in tmp/test/bazaar_repository) and see if you such merges appear in the repository (chance is: if they are in there, they are tested, if not, then definitely not)?

I ran that, and the resulting test repository just has 4 simple commits on a single level, no merges or anything.

I'll poke around at the Redmine code a little to see if I can figure out if there is a quick way to fix this.

In the mean time, I'll explain what I've learned about the way Bazaar does revisions. When you merge, it actually renames the revision number of previous revisions, and the revision number is what Redmine goes by. I still haven't fully grasped how and when it changes revision numbers, but here is how I think it works.

Say there are two development branches, B and C. Both branches are in sync up to revision number 10. Now there is parallel development going on in both branches. Developer on branch B creates revisions 11 and 12 on branch B. Meanwhile, another developer makes his own revisions 11, 12, 13, and 14 on branch C.

The developer on branch B then must do a merge with branch C if he wants to get the C branch revisions 11, 12, 13, and 14. After the merge, the revisions that were called 11, 12, 13, and 14 on branch C are renamed to 10.1, 10.2, 10.3, and 10.4, since 10 was the last common revision. The branch B revisions 11 and 12 stay numbered as 11 and 12, and the commit after the merge creates a revision 13. Now branch C can pull changes from branch B (no merge necessary) and the revisions will get renamed on branch C as well.

When using the bzr command line tool bzr log, by default, revisions 10.1, 10.2, 10.3, and 10.4 (second level revisions) won't show up, you need to specify bzr log -n 0 to show all levels.

A quick "hack" that I can think of that may or may not work is to change Redmine to not even use the "revision number" but instead use the "revision-id" (use --show-ids with bzr log to see these). The revision id is sorta like a git revision number, it's the email address of the author, followed by a timestamp, followed by some sort of hash tag, these don't change as far as I know when merges are done.

As I said, no bazaar user in the closer round of redmine devs, but feel free to send patches if they are well-tested :-) I think the subversion adapter and the git adapter to a lesser extent would be those to go by in terms of "interface".

As to the revision number and revision id thing: yes, redmine actually uses the revision number/commit hash as unique and unchanging key for repositories, so it seems you'd have to go by the revision-id (or even better, just the hash if it is unique) for bazaar to work correctly with redmine.

Please refer #3559 and #2799.

And please see #3909.

And please see http://bitbucket.org/yuja/redmine-mq-issue4455/issue/4/bad-revision-identifier-on-bazaar-darcs

I've been working on this some and have it working as far as I can tell. I have NOT attempted to write test code for this yet, in fact, rake test is failing because of the changes that I made, so it's certainly not ready to be a patch yet. But I'll keep working on getting it cleaned up and tests written. It's up at http://github.com/brentsowers1/redmine if you need to get Bazaar working now and are willing to risk using this without backing test code.

Mercurial has same problem of changing revision number when history editing (#3724).
In Mercurial, history editing of public repository is rare case.

If 'close #issue_number" is written in commit log, redmine add 'rNN' at a journal.
This is serious problem.

• http://www.redmine.org/issues/4455#note-151
• http://www.redmine.org/issues/4455#note-155