| @@ -47,6 +47,21 class Repository::Git < Repository | |||
|
|
47 | 47 | scm.tags |
|
|
48 | 48 | end |
|
|
49 | 49 | |
|
|
50 | # In Git and Mercurial, revisions are not in date order. | |
|
|
51 | # Mercurial fixed issues. | |
|
|
52 | # * Redmine Takes Too Long On Large Mercurial Repository | |
|
|
53 | # http://www.redmine.org/issues/3449 | |
|
|
54 | # * Sorting for changesets might go wrong on Mercurial repos | |
|
|
55 | # http://www.redmine.org/issues/3567 | |
|
|
56 | # Database revision column is text, so Redmine can not sort by revision. | |
|
|
57 | # Mercurial has revision number, and revision number guarantees revision order. | |
|
|
58 | # Mercurial adapter uses "hg log -r 0:tip --limit 10" | |
|
|
59 | # to get limited revisions from old to new. | |
|
|
60 | # And Mercurial model stored revisions ordered by database id in database. | |
|
|
61 | # So, Mercurial can use correct order revisions. | |
|
|
62 | # | |
|
|
63 | # But, Git 1.7.3.4 does not support --reverse with -n or --skip. | |
|
|
64 | # | |
|
|
50 | 65 | # With SCM's that have a sequential commit numbering, redmine is able to be |
|
|
51 | 66 | # clever and only fetch changesets going forward from the most recent one |
|
|
52 | 67 | # it knows about. |
General Comments 0
You need to be logged in to leave comments.
Login now