#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: | v3.6 |
Severity: | minor | Keywords: | Env. SVN fortran v3.6 |
Cc: |
Description
Context
When displaying namelists under TracBrowser, 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.
Changes
Set the SVN MIME type property to text/x-fortran for all namelists.
Commit History (2)
Changeset | Author | Time | ChangeLog |
---|---|---|---|
8601 | nicolasmartin | 2017-10-06T12:16:39+02:00 | Setting SVN property for syntax highlighting under Trac [refs #1948] |
8599 | nicolasmartin | 2017-10-06T11:56:40+02:00 | Setting SVN property for syntax highlighting under Trac [refs #1948] |
Change History (5)
comment:1 Changed 6 years ago by nicolasmartin
comment:2 Changed 6 years ago by nicolasmartin
In 8601:
comment:3 Changed 6 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. [auto-props] ... *.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 6 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:
- The developer will push his changes to the repository with the new syntax for the commit message, see #1948 as example.
- 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.
- The developer contacts the reviewer(s), the assignment of the ticket could be a clever method to do this.
- 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')
- 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.
comment:5 Changed 2 years ago by nemo
- Keywords Env. v3.6 added
In 8599: