From 4fc2e757f6d02ec541a4e0371cd6d8a08f15ac24 Mon Sep 17 00:00:00 2001 From: Toshi MARUYAMA Date: Wed, 4 May 2011 23:43:40 +0000 Subject: [PATCH] Merged r5644 from trunk. scm: git: add comments of revision order in fetch_changesets(). git-svn-id: svn+ssh://rubyforge.org/var/svn/redmine/branches/1.1-stable@5646 e93f8b46-1217-0410-a6f0-8f06a7374b81 --- app/models/repository/git.rb | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/app/models/repository/git.rb b/app/models/repository/git.rb index c90862995..e93adc717 100644 --- a/app/models/repository/git.rb +++ b/app/models/repository/git.rb @@ -47,6 +47,21 @@ class Repository::Git < Repository scm.tags end + # In Git and Mercurial, revisions are not in date order. + # Mercurial fixed issues. + # * Redmine Takes Too Long On Large Mercurial Repository + # http://www.redmine.org/issues/3449 + # * Sorting for changesets might go wrong on Mercurial repos + # http://www.redmine.org/issues/3567 + # Database revision column is text, so Redmine can not sort by revision. + # Mercurial has revision number, and revision number guarantees revision order. + # Mercurial adapter uses "hg log -r 0:tip --limit 10" + # to get limited revisions from old to new. + # And Mercurial model stored revisions ordered by database id in database. + # So, Mercurial can use correct order revisions. + # + # But, Git 1.7.3.4 does not support --reverse with -n or --skip. + # # With SCM's that have a sequential commit numbering, redmine is able to be # clever and only fetch changesets going forward from the most recent one # it knows about. -- 2.39.5