Redmine

Oh, I should mention I didn't implement this as a configurable setting as requested. Maybe later...

Agreed Felix. I'll work on moving it at least into a variable if not into a setting. Also, sorry about changing the ticket status, I'll know now not to do that anymore.

Adam Soltys wrote:

Ok, I've implemented this as a setting now. I figure this way it's not necessary to have separate values in each adapter. I've defaulted the value to 8. If someone with an svn repository with over 10 million revisions needs to increase this, they can!

Your patch is great!
Can you implement setting of "7.days" at source:tags/1.0.0/app/models/repository/git.rb#L50 and http://www.redmine.org/attachments/3272/git-fast-browse.patch in #4773 ?

I just realized I was incorrectly using the log_display_limit setting instead of the truncation setting in a couple places of code. Fixed that. Here's the patch again with just the truncation setting addressing the original issue, this time done properly.

I've also placed this change in a "for-eric" branch on my github fork and sent him a pull request. http://github.com/asoltys/redmine/tree/for-eric

Adam Soltys wrote:

Toshi, ok, I did these two things as settings for you, but I don't actually think they should be included in trunk and presented to the average user. They're specific to git, for one thing, and they deal with some pretty obscure internal performance mechanisms.

7.days problem is reported at #6013 and "git log -n 1 FILE_or_DIR" problem is reported at #5096.

Thanks for pointing to those issues Toshi. I hadn't been following redmine development for the last year or so but I'm glad to see that other people have taken up the charge on these matters. I was exposed first-hand to some of the general performance problems that redmine has with distributed scm's back when I worked on #1406, so I've gained an appreciation and desire to fix these things once and for all.

I still don't agree with exposing these two settings at the moment because I still see them as temporary hacks to solve performance problems that I think we could do better on. In particular, I have some ideas about possibly pre-fetching and caching some repository history or implementing some more sophisticated on-demand lookups and partial history scans that might give us adequate performance without requiring users to sacrifice the "last revision" field or manually specify how far back to look for dirty changesets.

I need to do a bit more thinking and design-work before I tackle a full-on reimplementation of the git and mercurial adapters though. So in the meantime I'm just trying to get my feet wet again with contributing to redmine. I do have plans to become a regular contributor through the coming fall and winter though and repository management and performance will be a central area of interest for me.

Didn't have the time to read everything but thank you guys for your work on these topics.

• I don't like the idea of introducing a Setting for that. There are already bunches of useless settings in redmine, and consulting administration panel always give me the feeling that we have too many things here which leads to confusion and bloat software ; I'd rather turn it into a constant in the class in a first approach. I think nobody cares Github truncates revision names to 7 or 8 chars because nobody reads these IDs, they're just here to point to the commit. We should have the same approach, decide a number (6? 7? 8? 10?) and begin with this.
• after some thoughts about it, I think this modification must be applied at adapter level, only to SCM with non sequential revision numbers.

Adam: can you confirm the last patch is the only one to keep ? We can delete other patches so that it's clearer which one to work on.

Yuya's implementation of Mercurial overhaul (#4455) shows activity with mercurial style such as 12:ff70262d476d .
You can see at http://dev.openttdcoop.org/projects/ttrs/activity .

I pushed yuya's mq to my github repository branch .

Jean-Baptiste Barth wrote:

About the original issue, I agree we should truncate git's sha1 revision names but I have 2 worries about it :

• I don't like the idea of introducing a Setting for that. There are already bunches of useless settings in redmine, and consulting administration panel always give me the feeling that we have too many things here which leads to confusion and bloat software ; I'd rather turn it into a constant in the class in a first approach. I think nobody cares Github truncates revision names to 7 or 8 chars because nobody reads these IDs, they're just here to point to the commit. We should have the same approach, decide a number (6? 7? 8? 10?) and begin with this.
• after some thoughts about it, I think this modification must be applied at adapter level, only to SCM with non sequential revision numbers.

Agreed, I'd go with 8 chars and an extra short_revision virtual attribute in the adapter.

Adam Soltys wrote:

In particular, I have some ideas about possibly pre-fetching and caching some repository history or implementing some more sophisticated on-demand lookups and partial history scans that might give us adequate performance without requiring users to sacrifice the "last revision" field or manually specify how far back to look for dirty changesets.

7.days is only git adapter problem.
There are some ideas of git at after note-13 of #4773 .

Because mercurial has revision number, Redmine can know mercurial "last committed revision"(tip) easily.
But mercurial tip is not latest revision (see note-23 of #4455 ).
This is the reason of Redmine 1.0.x mercurial adapter fetching performance problem.
Yuya fixed this problem at note-144 of #4455 and I pushed to my github hg-patches-svntrunk branch .

Thanks for looking at this Jean-Baptiste. I agree with you about the importance of avoiding software bloat and I don't like exposing obscure technical settings to the users either.

I'll have to look at the code though to see if it's possible to move this setting into the adapters. I think in some places where the revisions are being shortened we don't have access to the adapter objects, which is why I went with a global setting, but maybe I can figure something out. So yes, the latest patch supersedes the other ones, but hold off on looking at it because I'll probably be coming up with another one soon in light of this latest discussion.

Toshi, thanks again for the info. I looked at Yuya's branch quickly and it seems like he's done a lot of good work that I need to take a closer look at.

Adam Soltys wrote:

Toshi, thanks again for the info. I looked at Yuya's branch quickly and it seems like he's done a lot of good work that I need to take a closer look at.

• implement Changeset#format_identifier and Revision#format_identifier
• pass changeset or revision object to format_revision and link_to_revision helpers,
  so that it can utilize #format_identifier

Adam Soltys wrote:

Toshi, ok, I did these two things as settings for you, but I don't actually think they should be included in trunk and presented to the average user. They're specific to git, for one thing, and they deal with some pretty obscure internal performance mechanisms.

A better solution in my opinion would be to revisit the git adapter and see if we can get some more performance out of it by default. If github can do it, so can we!

Github seems to use Ajax for calling "git log -n 1 FILE_or_DIR".

Redmine calls "git log -n 1 FILE_or_DIR" not only in browsing directory tree but also in cat/diff/annotate.
Because entry() of abstract_adapter.rb calls entries() at source:tags/1.0.1/lib/redmine/scm/adapters/abstract_adapter.rb#L84 .

Adam Soltys wrote:

I need to do a bit more thinking and design-work before I tackle a full-on reimplementation of the git and mercurial adapters though. So in the meantime I'm just trying to get my feet wet again with contributing to redmine. I do have plans to become a regular contributor through the coming fall and winter though and repository management and performance will be a central area of interest for me.

Adam, please consider #5357.
Mercurial has same problem (#3567).
Yuya fixed this problem at note-144 of #4455.

FYI:
Bazaar merged revisions don't show up

Toshi MARUYAMA wrote:

"git log -n 1 FILE_or_DIR" problem is reported at #5096.

I found JPL posted a patch for this problem at note-13 of #1435 .
But current redmine support git branch, this patch is incompatible.

#3244, #3945 and #6092 are duplicate.