Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#1948 closed Task (fixed)

SVN mime-type for namelists to enable syntax highlighting

Reported by: nicolasmartin Owned by: nicolasmartin
Priority: low Milestone: 2017 WP
Component: env Version: release-3.6
Severity: minor Keywords: SVN fortran
Cc: Branch review: failed
MP ready?: no Task progress: Unspecified



When displaying namelists under Trac Browser, the content is not well rendered with highlighting (raw text) because namelist doesn't have an extension related to Fortran and the svn:mime-type property is not defined accordingly.


Set the SVN MIME type property to text/x-fortran for all namelists.

Commit History (2)


Setting SVN property for syntax highlighting under Trac [refs #1948]


Setting SVN property for syntax highlighting under Trac [refs #1948]

Change History (4)

comment:1 Changed 4 years ago by nicolasmartin

In 8599:

Setting SVN property for syntax highlighting under Trac [refs #1948]

comment:2 Changed 4 years ago by nicolasmartin

In 8601:

Setting SVN property for syntax highlighting under Trac [refs #1948]

comment:3 Changed 4 years ago by nicolasmartin

  • Resolution set to fixed
  • Status changed from new to closed

Done for the trunk and 3.6.

For developers attention, you can enable the setting of automatic properties for new files based on the filename pattern by configuring your local svn settings (edit ~/.subversion/config)

### for 'svn add' and 'svn import', it defaults to 'no'.
### Automatic properties are defined in the section 'auto-props'.
enable-auto-props = yes
### Section for configuring automatic properties.
*.sh = svn:eol-style=native;svn:executable
*.png = svn:mime-type=image/png
namelist_* = svn:mime-type=text/x-fortran

As I'm working now on the svn hooks, I will try to code a pre-commit hook that takes care of keeping this.

comment:4 Changed 4 years ago by nicolasmartin

  • Milestone set to 2017 WP
  • Severity set to minor
  • Type changed from Enhancement to Task

Changes for testing purpose to see if the review plugin is fully operational now.

Over time, the development workflow would become something close to the following:

  1. The developer will push his changes to the repository with the new syntax for the commit message, see #1948 as example.
  2. Thanks to this, the commit will create a new comment in the ticket with the commit message and display the status of the review as 'Pending' for default.
  3. The developer contacts the reviewer(s), the assignment of the ticket could be a clever method to do this.
  4. The reviewer(s) put his review directly in the changeset page of the commit (see bottom of page), there is a textarea for comments and dropdown menu for status ('Pending' | 'Failed' | 'Passed')
  5. The review submitted will become a new comment in the ticket and the branch_review custom field will be updated appropriately regarding the review status.

The review can be modified and the developer can link as much commits as he wants to a development ticket but by design there will be only one status for branch_review custom field.

Last edited 4 years ago by nicolasmartin (previous) (diff)
Note: See TracTickets for help on using tickets.