Yeah this is a problem for us too. It's very fragile and something as simple as removing a changeset with screw up ALL the links. This really needs to be fixed.
--------------------------------------------------------------------------------
The attached patch addresses your concern, and I'm all for moving away from the ambiguous revision numbers, but this sort of behavioural change probably requires a configuration option, since it will definitely break any existing r##-style references... comments?
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Actually, there are some further changes to be made in app/models/repository/mercurial.rb
--------------------------------------------------------------------------------
Peter Fern wrote:
> The attached patch addresses your concern, and I'm all for moving away from the ambiguous revision numbers, but this sort of behavioural change probably requires a configuration option, since it will definitely break any existing r##-style references... comments?

Probably a conversion script of the r##-style references to hashes would be best. Thanks for doing this!
--------------------------------------------------------------------------------
Just an update - I have a significant Mercurial patch near completion that addresses this issue, plus a number of others, please ignore my previous attachment.
--------------------------------------------------------------------------------
Awesome. Look forward to it.

I don't see why it'd break r##, though - like I mentioned above, hg understands several kinds of references to changesets, so what's preventing redmine from allowing all three and just passing along whatever identifier to the client?
--------------------------------------------------------------------------------
There are two keys in the Redmine database - revision and scmid, however Mercurial has 3 identifiers: revision, short changeset ID, and full changeset ID. Since revision is likely to get clobbered, and even the short changeset ID is not _guaranteed_ to remain unique, I'd like to move to using the short ID as the revision, and the full ID as the scmid, since this is the only way we'll have a guaranteed unique identifier in the DB, and if the revision number gets routinely clobbered by merges, it's pretty useless anyway, since any references to it will now refer to some other commit.
--------------------------------------------------------------------------------
Peter Fern wrote:
> Just an update - I have a significant Mercurial patch near completion that addresses this issue, plus a number of others, please ignore my previous attachment.

If you're working on a big Mercurial update, you may want to take a look at issue r3421. Mercurial is more or less useless without it in Redmine.
--------------------------------------------------------------------------------
Luke Hoersten wrote:
> Peter Fern wrote:
> > Just an update - I have a significant Mercurial patch near completion that addresses this issue, plus a number of others, please ignore my previous attachment.
>
> If you're working on a big Mercurial update, you may want to take a look at issue r3421. Mercurial is more or less useless without it in Redmine.

Sorry that's issue #3421.
--------------------------------------------------------------------------------
I wouldn't say that - the only thing that doesn't work is file sizes... my patch incorporates branch and tag support like git, plus major performance improvements. I'll have it up in the next day or so. I've added a comment to #3421
--------------------------------------------------------------------------------
Peter Fern wrote:
> I wouldn't say that - the only thing that doesn't work is file sizes... my patch incorporates branch and tag support like git, plus major performance improvements. I'll have it up in the next day or so. I've added a comment to #3421

You understand what #3421 is fixing right? Redmine pulls the history from the repo but file access is attempted on the file system instead of using 'hg cat' to grab what's in the changeset specified.
--------------------------------------------------------------------------------
I think you'll find that's incorrect, and looking at the patch, it doesn't modify the 'cat' method in any way other than to add a default identifier of 'tip'. The only file access the the Mercurial code is to get file sizes, which I'd be happy to see resolved since it's the last functional hole in my patchset.
--------------------------------------------------------------------------------
As a user of the Mercurial plugin, I want to add my $.02 here.

Just as there is a reason for the globally-unique changeset hash id, there is also a reason for the integer revision id as well. I currently *rely* on Redmine as the source for access to the integer id, and removing it completely would break my build system implementation.

While a changeset hash is useful when discussing revisions between developers, it is unfortunately both completely unsuitable for use in build numbering of packages as well as being hostile to the human eye. Because of the necessity of numbering our builds with the revision number, in order to trace back any build package to the source code which created it, we simply make sure that our developers know of the mutability of the integer revision id and use the build repository as its authoritative source. This is simply the added cost of using a system like Mercurial, that you have to keep in mind something extra like the scope of the revision id.

It's not simply a matter of saying "suck it up, use the hash", either. When building .NET assemblies, the revision number must fit within a 16-bit integer. A hash can't possibly do this. Even if it were possible, however, I still wouldn't inflict hash numbers on our customers as a means of identifying a package.

So, whatever change you make, I would ask that both it preserve the integer revision id, as well as allowing r-style links in Redmine and being available in both the Repository view as well as the atom feed for the repository. Otherwise, Redmine's mercurial functionality will be significantly less useful to developers like me.
--------------------------------------------------------------------------------
From the "Mercurial book":http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html :

> [...] the same number in two different clones of a repository may identify different changesets.

What that means is if you swap out the repo for a modified clone, potentially all your short numbers which you've "hardcoded" into the Redmine issues/comments would be invalidated.

I want my Redmine comments to refer to a _specific_ changeset, not a specific _clone's changeset_. Perhaps if you're using Mercurial in a more centralized manor this is fine, but my team doesn't work that way.

Ted Lilley wrote:
> As a user of the Mercurial plugin, I want to add my $.02 here.
>
> Just as there is a reason for the globally-unique changeset hash id, there is also a reason for the integer revision id as well. I currently *rely* on Redmine as the source for access to the integer id, and removing it completely would break my build system implementation.
>
> While a changeset hash is useful when discussing revisions between developers, it is unfortunately both completely unsuitable for use in build numbering of packages as well as being hostile to the human eye. Because of the necessity of numbering our builds with the revision number, in order to trace back any build package to the source code which created it, we simply make sure that our developers know of the mutability of the integer revision id and use the build repository as its authoritative source. This is simply the added cost of using a system like Mercurial, that you have to keep in mind something extra like the scope of the revision id.
>
> It's not simply a matter of saying "suck it up, use the hash", either. When building .NET assemblies, the revision number must fit within a 16-bit integer. A hash can't possibly do this. Even if it were possible, however, I still wouldn't inflict hash numbers on our customers as a means of identifying a package.
>
> So, whatever change you make, I would ask that both it preserve the integer revision id, as well as allowing r-style links in Redmine and being available in both the Repository view as well as the atom feed for the repository. Otherwise, Redmine's mercurial functionality will be significantly less useful to developers like me.

--------------------------------------------------------------------------------
Please see #4455 - Mercurial overhaul.

--------------------------------------------------------------------------------
Luke Hoersten wrote:
> From the "Mercurial book":http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html :
>
> > [...] the same number in two different clones of a repository may identify different changesets.
>
> What that means is if you swap out the repo for a modified clone, potentially all your short numbers which you've "hardcoded" into the Redmine issues/comments would be invalidated.
>

This is a very serious problem. But there is no way to resolve this problem simply. Because scmid of changeset table is not unique and revision is unique.

--------------------------------------------------------------------------------
Luke Hoersten wrote:
>
> What that means is if you swap out the repo for a modified clone, potentially all your short numbers which you've "hardcoded" into the Redmine issues/comments would be invalidated.

h2. 1

<pre>
/- B
A--------C

DB hg
0 A 0 A
1 B 1 B
2 C 2 C
</pre>

h2. 2

<pre>
A---C

DB hg
0 A 0 A
1 B 1 C
2 C
</pre>

h2. 3

<pre>
/-----D
A---C

DB hg
0 A 0 A
1 B 1 C
2 C 2 D
</pre>

h2. 4

<pre>
/--------B
/-----D
A---C

DB hg
0 A 0 A
1 B 1 C
2 C 2 D
3 B 3 B

</pre>

--------------------------------------------------------------------------------
I finish testing of last big feature of #4455.
This feature is *"old rNN record on DB and wikis can not delete"*.
http://github.com/marutosi/redmine/tree/hg-overhaul-0.9
http://github.com/marutosi/redmine/commit/30845a8c8ed51a71beb6e1d4df4dfbcf3a55c444

--------------------------------------------------------------------------------
I really hope, Mercurial will at least keep the option to use the revision number. That is in fact one of the big advantages compared to git, I am aware of the possibility to have same repo with different orders of changesets, but that doesn't matter, if you define server/buildsystem repo as master repo.

Please keep at least revision number for Mercurial as option.

I also changed hgweb to show revision numbers instead short hashes.
--------------------------------------------------------------------------------
Thank you for your feedback.
Yuya's #4455 new implementation keeps redmine original DB structure.
Please see http://www.redmine.org/issues/4455#note-78 .

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
To Toshi: JFTR, the arguments of @assert_equal@ are @expected, actual@

r4654 "trunk/test/unit/repository_mercurial_test.rb":http://www.redmine.org/projects/redmine/repository/revisions/4654/diff/trunk/test/unit/repository_mercurial_test.rb

<pre><code class="ruby">
assert_equal @repository.find_changeset_by_name(r).revision, '2'
</code></pre>

should be

<pre><code class="ruby">
assert_equal '2', @repository.find_changeset_by_name(r).revision
</code></pre>

--------------------------------------------------------------------------------
Yuya Nishihara wrote:
> To Toshi: JFTR, the arguments of @assert_equal@ are @expected, actual@
>
> r4654 "trunk/test/unit/repository_mercurial_test.rb":http://www.redmine.org/projects/redmine/repository/revisions/4654/diff/trunk/test/unit/repository_mercurial_test.rb
>
> [...]
>
> should be
>
> [...]

I fixed and committed. Thanks.

--------------------------------------------------------------------------------
I think there are two cases of revision number inconsistency.

* History editing (hg strip, hg rebase etc.)
* Replacing repository

If you did history editing, you need to delete repository from redmine and re-add it.
There are some feature issues of re-syncing #1273.

About replacing repository, I wrote at #6681 description.

I think Mercurial user should not use "rNN" in wiki.
If someone wrote "rNN" in wiki, it is user's own risk.
#6681 changed auto close issue text from "rNN" to "commit:XXX".

Redmine stores revision number and changeset id in database.
To resolve this issue, we changed as following.

* Change revision text to Mercurial style "2:400bb8672109"
* Change revision link from revision number to changeset id
* Redmine URL accepts both of revision number and changeset id
* diff, cat and annotate accepts both of revision number and changeset id

h2. Before

!before-repository.png!
!before-link.png!
!before-annotate.png!

h2. After

!after-repository.png!
!after-link-id.png!
!after-link-revno.png!
!after-annotate.png!

--------------------------------------------------------------------------------

relates,Closed,6092,Truncate Git revision labels in Activity page/feed and allow configurable length
relates,Closed,4924,mercurial reader disregard information from non-default branch
relates,Closed,6681,Mercurial, Bazaar and Darcs auto close issue text should be commit id instead of revision number
relates,Closed,4455,Mercurial overhaul
relates,Closed,7518,Mercurial diff can be wrong if the previous changeset isn't the parent
relates,New,8030,Bazaar integration doesn't notice new commits to repository
relates,Closed,5501,Git: Mercurial: Adding visual merge/branch history to repository view