fixing [changeset] tags and repository browser

24 views
Skip to first unread message

Josh Santangelo

unread,
May 14, 2015, 7:20:34 PM5/14/15
to trac-...@googlegroups.com
My Trac setup comprises many projects supported by SimpleMultiProjectPlugin, and many repositories specified in the admin interface. I was also using the GitHub plugin, but have since moved away from GitHub and removed the plugin. Now, the results of a trac-admin env changeset command result in something like "In [changeset:"ae451ea72898091ac0fdcf74bc5aa21794f943c1/GGR"]:" being added to a ticket. I'm wondering how to get the changeset links working again, and directing to the internal source browser.

The TracGit page seems to indicate that I should specify a repository_dir, but since I have many, that doesn't seem to make sense. It looks like perhaps I could define multiple repositories in a [repositories] block, but that's in 1.1+.

Am I just out of luck unless I switch to the 1.1 branch of trac?

thanks,
-josh

RjOllos

unread,
May 15, 2015, 2:41:06 AM5/15/15
to trac-...@googlegroups.com
Trac supports the [repositories] section since 0.12, when multi-repository support was added. That documentation section is just saying that when you specify a repository when creating an environment in Trac < 1.1.3, the configuration will be added to the [trac] section. That's the old, now deprecated single-repository way of specifying the configuration, and we really should have modified the TracAdmin initenv command back in Trac 0.12 to create the repository in the [repositories] section. In Trac 1.1.3 we removed the [trac] repository_dir option, added an upgrade step will modify trac.ini to add an equivalent repositories section and modified the initenv command to add repositories to the [repository] section of trac.ini.

So I suggest:
2. move your configuration to the [repositories] section (not required unless you want to support multiple repositories, but might as well do it anyway)
3. run ` trac-admin $env repository resync "(default)" ` (and repeat for every other repository if you have multiple repositories).

I feel like I'm probably not understanding something about your configuration and why new ticket changesets links would be directing to GitHub if the plugin has been removed. You may need to modify your post-commit hook. IIRC GitHub plugin used a post-commit hook other than the Trac default one.

- Ryan

Josh Santangelo

unread,
May 21, 2015, 5:04:18 PM5/21/15
to trac-...@googlegroups.com
On May 14, 2015, at 11:41 PM, RjOllos <rjo...@gmail.com> wrote:

On Thursday, May 14, 2015 at 4:20:34 PM UTC-7, Josh Santangelo wrote:
My Trac setup comprises many projects supported by SimpleMultiProjectPlugin, and many repositories specified in the admin interface. I was also using the GitHub plugin, but have since moved away from GitHub and removed the plugin. Now, the results of a trac-admin env changeset command result in something like "In [changeset:"ae451ea72898091ac0fdcf74bc5aa21794f943c1/GGR"]:" being added to a ticket. I'm wondering how to get the changeset links working again, and directing to the internal source browser.

The TracGit page seems to indicate that I should specify a repository_dir, but since I have many, that doesn't seem to make sense. It looks like perhaps I could define multiple repositories in a [repositories] block, but that's in 1.1+.

Am I just out of luck unless I switch to the 1.1 branch of trac?

Trac supports the [repositories] section since 0.12, when multi-repository support was added. That documentation section is just saying that when you specify a repository when creating an environment in Trac < 1.1.3, the configuration will be added to the [trac] section. That's the old, now deprecated single-repository way of specifying the configuration, and we really should have modified the TracAdmin initenv command back in Trac 0.12 to create the repository in the [repositories] section. In Trac 1.1.3 we removed the [trac] repository_dir option, added an upgrade step will modify trac.ini to add an equivalent repositories section and modified the initenv command to add repositories to the [repository] section of trac.ini.

Good that [repositories] is supported in my version of Trac, but it’s still unclear to me what to put in there. The docs show:

[repositories]
.type = git
.dir = /path/to/my/git/repository/.git

Do I just repeat .type and .dir for each repository? Is something supposed to go before the dot? 

And what is the difference between [repositories] and the /admin/versioncontrol/repository page, where I already have all of my repositories entered?

So I suggest:
2. move your configuration to the [repositories] section (not required unless you want to support multiple repositories, but might as well do it anyway)
3. run ` trac-admin $env repository resync "(default)" ` (and repeat for every other repository if you have multiple repositories).

I feel like I'm probably not understanding something about your configuration and why new ticket changesets links would be directing to GitHub if the plugin has been removed. You may need to modify your post-commit hook. IIRC GitHub plugin used a post-commit hook other than the Trac default one.

I probably wasn’t very clear — my changeset links aren’t directing to GitHub — they’re directing to nothing at all. Here is a screenshot.


I haven’t been using a post-commit hook, I’ve been using a script which polls my repos and calls "trac-admin env changeset added" when new commits show up. It’s sort of janky but mostly works.

thanks,
-josh

RjOllos

unread,
May 22, 2015, 2:46:08 AM5/22/15
to trac-...@googlegroups.com


On Thursday, May 21, 2015 at 2:04:18 PM UTC-7, Josh Santangelo wrote:
Good that [repositories] is supported in my version of Trac, but it’s still unclear to me what to put in there. The docs show:

[repositories]
.type = git
.dir = /path/to/my/git/repository/.git

Do I just repeat .type and .dir for each repository? Is something supposed to go before the dot? 

Yes, the repository name goes before the dot. If you omit the repository name, then you are referring to the default repository, which can also be referred to using the notation "(default)" (for example, when using trac-admin $env repository resync $repos -> trac-admin $env repository resync resync "(default)").
 
And what is the difference between [repositories] and the /admin/versioncontrol/repository page, where I already have all of my repositories entered?

They are different repository data stores. You can use either, or even define different repositories in each, though that's probably not recommended.

I've done some work over the past few days to try and clarify the documentation. I appreciate if you can read and suggest any areas that you find confusing, redundant or lacking information:
 
I probably wasn’t very clear — my changeset links aren’t directing to GitHub — they’re directing to nothing at all. Here is a screenshot.


I haven’t been using a post-commit hook, I’ve been using a script which polls my repos and calls "trac-admin env changeset added" when new commits show up. It’s sort of janky but mostly works.

Do you have "tracopt.ticket.commit_updater.* = enabled" in your [components] section?

Josh Santangelo

unread,
May 22, 2015, 11:23:26 AM5/22/15
to trac-...@googlegroups.com
On May 21, 2015, at 11:46 PM, RjOllos <rjo...@gmail.com> wrote:

On Thursday, May 21, 2015 at 2:04:18 PM UTC-7, Josh Santangelo wrote:
Good that [repositories] is supported in my version of Trac, but it’s still unclear to me what to put in there. The docs show:

[repositories]
.type = git
.dir = /path/to/my/git/repository/.git

Do I just repeat .type and .dir for each repository? Is something supposed to go before the dot? 

Yes, the repository name goes before the dot. If you omit the repository name, then you are referring to the default repository, which can also be referred to using the notation "(default)" (for example, when using trac-admin $env repository resync $repos -> trac-admin $env repository resync resync "(default)”).

Gotcha. But since I’ve got the repositories configured in the database via the admin panel, specifying them in [respositories] isn’t necessary, right?

And what is the difference between [repositories] and the /admin/versioncontrol/repository page, where I already have all of my repositories entered?

They are different repository data stores. You can use either, or even define different repositories in each, though that's probably not recommended.

I've done some work over the past few days to try and clarify the documentation. I appreciate if you can read and suggest any areas that you find confusing, redundant or lacking information:

This is definitely quite a bit more clear.

 
I probably wasn’t very clear — my changeset links aren’t directing to GitHub — they’re directing to nothing at all. Here is a screenshot.


I haven’t been using a post-commit hook, I’ve been using a script which polls my repos and calls "trac-admin env changeset added" when new commits show up. It’s sort of janky but mostly works.

Do you have "tracopt.ticket.commit_updater.* = enabled" in your [components] section?

Yes, that’s in there. My understanding is that’s what causes the commit comments to be added to the tickets. That’s working correctly, it’s just that the text in the comment doesn’t link to anything.

RjOllos

unread,
May 26, 2015, 5:56:44 PM5/26/15
to trac-...@googlegroups.com


On Friday, May 22, 2015 at 11:23:26 AM UTC-4, Josh Santangelo wrote: 
Gotcha. But since I’ve got the repositories configured in the database via the admin panel, specifying them in [respositories] isn’t necessary, right?
Correct, no need to specify the repositories in multiple repository stores.
 



Do you have "tracopt.ticket.commit_updater.* = enabled" in your [components] section?

Yes, that’s in there. My understanding is that’s what causes the commit comments to be added to the tickets. That’s working correctly, it’s just that the text in the comment doesn’t link to anything.

Good point. With that in mind, the next things I would do are:
 - Confirm there is a repository or alias named "OWW"
 - Resync the repository

Josh Santangelo

unread,
May 31, 2015, 5:52:24 PM5/31/15
to trac-...@googlegroups.com

On May 26, 2015, at 2:56 PM, RjOllos <rjo...@gmail.com> wrote:

Do you have "tracopt.ticket.commit_updater.* = enabled" in your [components] section?

Yes, that’s in there. My understanding is that’s what causes the commit comments to be added to the tickets. That’s working correctly, it’s just that the text in the comment doesn’t link to anything.

Good point. With that in mind, the next things I would do are:
 - Confirm there is a repository or alias named "OWW"
 - Resync the repository

/admin/versioncontrol/repository does show it:
OWW  (default) C:\​Stimulant\​Source\​OWW.git  [58651e6] 

resync:

C:\Users\trac>trac-admin c:\trac\stimulant repository resync "OWW"
Resyncing repository history for OWW...
0 revisions cached.
Done.


Should that have changed anything?

RjOllos

unread,
May 31, 2015, 6:14:54 PM5/31/15
to trac-...@googlegroups.com
Yes, I think it should have cached all revisions in the repository.

What are your settings for?:
 - [trac] default_repository_type
 - [git] persistent_cache
 - [git] cached_repository
 - [trac] repository_sync_per_request

Could you resync again with log level set to DEBUG and post the output?

Josh Santangelo

unread,
May 31, 2015, 7:33:03 PM5/31/15
to trac-...@googlegroups.com
On May 31, 2015, at 3:14 PM, RjOllos <rjo...@gmail.com> wrote:

On Sunday, May 31, 2015 at 5:52:24 PM UTC-4, Josh Santangelo wrote:

On May 26, 2015, at 2:56 PM, RjOllos <rjo...@gmail.com> wrote:

Do you have "tracopt.ticket.commit_updater.* = enabled" in your [components] section?

Yes, that’s in there. My understanding is that’s what causes the commit comments to be added to the tickets. That’s working correctly, it’s just that the text in the comment doesn’t link to anything.

Good point. With that in mind, the next things I would do are:
 - Confirm there is a repository or alias named "OWW"
 - Resync the repository

/admin/versioncontrol/repository does show it:
OWW  (default) C:\​Stimulant\​Source\​OWW.git  [58651e6] 

resync:

C:\Users\trac>trac-admin c:\trac\stimulant repository resync "OWW"
Resyncing repository history for OWW...
0 revisions cached.
Done.


Should that have changed anything?

Yes, I think it should have cached all revisions in the repository.

What are your settings for?:
 - [trac] default_repository_type

I don’t see anything for that in trac.ini, but the admin UI shows a default of git:

 - [git] persistent_cache
 - [git] cached_repository

My [git] section shows only git_bin and projects_base…

[git]
git_bin = C:\Progra~2\Git\cmd\git.exe
projects_base = c:\stimulant\source

 - [trac] repository_sync_per_request

I found…

repository_dir = 
repository_sync_per_request = 
repository_type = git

Could you resync again with log level set to DEBUG and post the output?

The last bits of the log when doing that…

2015-05-31 16:31:37,167 Trac[environmentSetup] DEBUG: SimpleMultiProject database schema version: 6 (should be 6)
2015-05-31 16:31:37,167 Trac[api] DEBUG: T&E BEGIN Reports need an upgrade check
2015-05-31 16:31:37,167 Trac[reportmanager] DEBUG: T&E Checking for custom_report upgrade
2015-05-31 16:31:37,183 Trac[reportmanager] DEBUG: T&E END Checking for custom_report upgrade
2015-05-31 16:31:37,183 Trac[api] DEBUG: T&E END Reports need an upgrade check
2015-05-31 16:31:37,183 Trac[api] DEBUG: T&E NEEDS UP?: sys:False, rep:False, stats:False, fields:False, man:False
2015-05-31 16:31:37,213 Trac[git_fs] INFO: detected GIT version 1.8.5.2.msysgit.0
2015-05-31 16:31:37,213 Trac[PyGIT] DEBUG: PyGIT.Storage instance 53996720 constructed
2015-05-31 16:31:37,213 Trac[PyGIT] DEBUG: requested weak PyGIT.Storage instance 53996720 for 'C:\Stimulant\Source\OWW.git'
2015-05-31 16:31:37,213 Trac[git_fs] DEBUG: disabled CachedRepository for 'C:\Stimulant\Source\OWW.git'
2015-05-31 16:31:37,213 Trac[PyGIT] DEBUG: triggered rebuild of commit tree db for 53996720
2015-05-31 16:31:37,308 Trac[PyGIT] DEBUG: rebuilt commit tree db for 53996720 with 223 entries (took 94.0 ms)


Ryan Ollos

unread,
May 31, 2015, 7:53:47 PM5/31/15
to trac-...@googlegroups.com
On Sun, May 31, 2015 at 7:32 PM, Josh Santangelo <jo...@stimulant.com> wrote:
2015-05-31 16:31:37,213 Trac[git_fs] DEBUG: disabled CachedRepository for 'C:\Stimulant\Source\OWW.git'

Could you try the following setting?

[git] cached_repository = true

 

Josh Santangelo

unread,
Jun 1, 2015, 12:18:39 PM6/1/15
to trac-...@googlegroups.com
That seemed to have some effect. Now in the log…

2015-06-01 09:12:42,582 Trac[PyGIT] DEBUG: requested weak PyGIT.Storage instance 54848720 for 'C:\Stimulant\Source\GGR.git'
2015-06-01 09:12:42,582 Trac[git_fs] DEBUG: enabled CachedRepository for 'C:\Stimulant\Source\GGR.git'
2015-06-01 09:12:42,582 Trac[cache] INFO: Cleaning cache
2015-06-01 09:12:42,864 Trac[cache] INFO: Resetting "repository_dir": git:C:\Stimulant\Source\GGR.git
2015-06-01 09:12:43,986 Trac[PyGIT] DEBUG: triggered rebuild of commit tree db for 54848720
2015-06-01 09:12:44,081 Trac[PyGIT] DEBUG: rebuilt commit tree db for 54848720 with 141 entries (took 94.0 ms)
2015-06-01 09:12:44,081 Trac[cache] DEBUG: cache metadata undefined (youngest_rev=u'')
2015-06-01 09:12:44,081 Trac[cache] INFO: repos rev [70683e76f0ff18f657001e3a37d8893042097381] != cached rev [None]
2015-06-01 09:12:44,081 Trac[cache] INFO: Trying to sync revision [a913e49568551b329223a9f3f52fa5356572dd89]
2015-06-01 09:12:44,158 Trac[cache] DEBUG: Caching node change in [a913e49568551b329223a9f3f52fa5356572dd89]: (u'README.md', 'file', 'add', '', None)
2015-06-01 09:12:44,174 Trac[cache] INFO: Trying to sync revision [168d2105a8f21f9e4d697553f2349c57cb4c8bea]
2015-06-01 09:12:44,190 Trac[cache] DEBUG: Caching node change in [168d2105a8f21f9e4d697553f2349c57cb4c8bea]: (u'config.json', 'file', 'add', '', None)
2015-06-01 09:12:44,190 Trac[cache] DEBUG: Caching node change in [168d2105a8f21f9e4d697553f2349c57cb4c8bea]: (u'package/background.js', 'file', 'add', '', None)
2015-06-01 09:12:44,190 Trac[cache] DEBUG: Caching node change in [168d2105a8f21f9e4d697553f2349c57cb4c8bea]: (u'package/full.html', 'file', 'add', '', None)
2015-06-01 09:12:44,190 Trac[cache] DEBUG: Caching node change in [168d2105a8f21f9e4d697553f2349c57cb4c8bea]: (u'package/icon_128.png', 'file', 'add', '', None)
2015-06-01 09:12:44,206 Trac[cache] DEBUG: Caching node change in [168d2105a8f21f9e4d697553f2349c57cb4c8bea]: (u'package/index.html', 'file', 'add', '', None)
2015-06-01 09:12:44,206 Trac[cache] DEBUG: Caching node change in [168d2105a8f21f9e4d697553f2349c57cb4c8bea]: (u'package/js/app.js', 'file', 'add', '', None)
2015-06-01 09:12:44,206 Trac[cache] DEBUG: Caching node change in [168d2105a8f21f9e4d697553f2349c57cb4c8bea]: (u'package/libs/ampm.js', 'file', 'add', '', None)
2015-06-01 09:12:44,206 Trac[cache] DEBUG: Caching node change in [168d2105a8f21f9e4d697553f2349c57cb4c8bea]: (u'package/libs/backbone.js', 'file', 'add', '', None)
2015-06-01 09:12:44,206 Trac[cache] DEBUG: Caching node change in [168d2105a8f21f9e4d697553f2349c57cb4c8bea]: (u'package/libs/jquery-2.1.3.js', 'file', 'add', '', None)
2015-06-01 09:12:44,206 Trac[cache] DEBUG: Caching node change in [168d2105a8f21f9e4d697553f2349c57cb4c8bea]: (u'package/libs/socket.io.js', 'file', 'add', '', None)
2015-06-01 09:12:44,206 Trac[cache] DEBUG: Caching node change in [168d2105a8f21f9e4d697553f2349c57cb4c8bea]: (u'package/libs/underscore.js', 'file', 'add', '', None)
2015-06-01 09:12:44,206 Trac[cache] DEBUG: Caching node change in [168d2105a8f21f9e4d697553f2349c57cb4c8bea]: (u'package/manifest.json', 'file', 'add', '', None)
2015-06-01 09:12:44,206 Trac[cache] DEBUG: Caching node change in [168d2105a8f21f9e4d697553f2349c57cb4c8bea]: (u'sharedState.js', 'file', 'add', '', None)
2015-06-01 09:12:44,206 Trac[cache] INFO: Trying to sync revision [46200b3c74e3323299b61e83d05ef5845e47bce8]
[…lots more of those…]


Didn’t seem to make any impact on the [changeset] tags in tickets, though.

RjOllos

unread,
Jun 1, 2015, 3:53:06 PM6/1/15
to trac-...@googlegroups.com


On Monday, June 1, 2015 at 12:18:39 PM UTC-4, Josh Santangelo wrote:
Didn’t seem to make any impact on the [changeset] tags in tickets, though.

I have overlooked something very obvious. It seems that "changeset" isn't being recognized as a TracLinks prefix, which points to the component implementing IWikiSyntaxProvider being disabled (i.e. ChangsetModule).

Is "trac.versioncontrol.web_ui.changeset.ChangesetModule" enabled in your environment?

- Ryan

Josh Santangelo

unread,
Jun 1, 2015, 3:58:59 PM6/1/15
to trac-...@googlegroups.com
Good thinking, yes, that was disabled according to the instructions of the GitHub plugin I had installed earlier.

I probably should have just searched for changeset in the ini, or revisited those instructions to undo what I’d done before.

Works now, thanks!

RjOllos

unread,
Jun 1, 2015, 4:17:59 PM6/1/15
to trac-...@googlegroups.com


On Monday, June 1, 2015 at 3:58:59 PM UTC-4, Josh Santangelo wrote:
Good thinking, yes, that was disabled according to the instructions of the GitHub plugin I had installed earlier.

I probably should have just searched for changeset in the ini, or revisited those instructions to undo what I’d done before.

Works now, thanks!

Okay, cool. You may want to keep an eye on repository browsing performance now that you have a "cached repository". The TracGit page (1) indicates that performance can be poor with more than 500 changesets, however I recall some work done recently to improve some aspects of the performance, so that information may less accurate if you are running Trac 1.0.6post2.

Also, I think you already have a post-receive hook (2) setup for Git since you indicated that CommitTicketUpdater is working for you, but you probably want to confirm that new changesets are cached immediately. You could do that by making a commit and then checking the Revision Log to confirm that the new changeset appears.

- Ryan

(1) http://trac.edgewall.org/wiki/TracGit?version=1#Troubleshooting
(2) http://trac.edgewall.org/wiki/TracGit?version=1#Settinguppost-receivehooks
Reply all
Reply to author
Forward
0 new messages