Remove deprecated [trac] repository_dir option for configuring repository

[Ryan J Ollos]

The repository_dir option in the [trac] section has been deprecated since 0.12 and has been marked as deprecated since that release, so it seems like we can safely remove it for release 1.2.

I also wonder if we should move the repository_sync_per_request and repository_type options to the [repositories] section, or somehow allow the values to be defined in either section for one major release while deprecating the options in the [trac] section.

[Ryan J Ollos]

Some thoughts:

• Would it be desirable to have an upgrade step that creates an entry in the [repositories] section of trac.ini, provided the entry doesn't already exist? For example:

  [trac]
  repository_dir = /path/to/repository
  repository_type = svn
  

  →

  [repositories]
  .dir = /path/to/repository
  .type = svn
  

  Or we could create an entry in the database rather than trac.ini.

• Some replacements would seem to be desirable in order to better organize the options (though I would make these changes in a different ticket):
  1. [trac] repository_type → [repositories] default_repository_type
  2. [trac] repository_sync_per_request → [repositories] <name>.sync_per_request (with the latter taking on values true and false, defaulting to false.
  3. [versioncontrol] allowed_repository_dir_prefixes → [repositories] allowed_repository_dir_prefixes

(3) was discussed in comment:8:ticket:9511. I'm not sure it is strictly true that [repositories] section could not be used. Of course, (2) is no problem. Assuming the options cannot go in the [repositories] section, the main goal should be to get those options out of the [trac] section, and they could be put in the [versioncontrol] section instead.

Initial changes in log:rjollos.git:t11703. All of the tests pass after these changes.

[Jun Omae]

Some thoughts:

• Would it be desirable to have an upgrade step that creates an entry in the [repositories] section of trac.ini, provided the entry doesn't already exist? For example: […] Or we could create an entry in the database rather than trac.ini.

That upgrade step sounds good. IMO, I think we should create an entry in trac.ini rather the database since the entry is in trac.ini.

• Some replacements would seem to be desirable in order to better organize the options (though I would make these changes in a different ticket): …

Sounds good if we provide upgrade step for that.

2. [trac] repository_sync_per_request → [repositories] <name>.sync_per_request (with the latter taking on values true and false, defaulting to false.

Interested. I think we should provide per repository ui and options. Currently, there is only eol_style option as a per repository option at branches/1.0-stable/tracopt/versioncontrol/svn/svn_fs.py@13019:333#L326​. See also mercurial-plugin/tracext/hg/backend.py@3bf996dd58c7:516#L503​.

[Ryan J Ollos]

At least 3 places in the documentation need to be updated with the removal of [trac] repository_dir. The locations I found grepping the documentation on the trunk are:

• TracEnvironment#SourceCodeRepository
• TracFineGrainedPermissions#TracConfiguration
• TracRepositoryAdmin#Repositories

[Ryan J Ollos]

Replying to jomae:

2. [trac] repository_sync_per_request → [repositories] <name>.sync_per_request (with the latter taking on values true and false, defaulting to false.

Interested. I think we should provide per repository ui and options. Currently, there is only eol_style option as a per repository option at branches/1.0-stable/tracopt/versioncontrol/svn/svn_fs.py@13019:333#L326​. See also mercurial-plugin/tracext/hg/backend.py@3bf996dd58c7:516#L503​.

Thanks, I'll have to look at that more closely to understand. Would it make sense to also have [trac] authz_file as a per repository option?

[Jun Omae]

Replying to rjollos:

Would it make sense to also have [trac] authz_file as a per repository option?

Yeah. However, I think we should leave this option with no changes. This option accepts path to the Subversion authz file. The Subversion authz file normally has path-based authorization for multiple repositories, Especially before Subversion 1.6.

After Subversion 1.7, new option allows to specify a per repository authz file. See ​AuthzSVNReposRelativeAccessFile.

[Ryan J Ollos]

Have you seen a formal statement in the Trac wiki about which Subversion releases are supported? Subversion 1.6 is ​no longer maintained. That's not to say we shouldn't support it for some time (particularly on 0.12.x and 1.0.x), but we don't need to support every release forever, and I doubt Subversion 1.5 at least should be supported in Trac 1.2. We should consider documenting supported versions in the TracDev/ReleaseNotes/1.0 or TracDev/ApiChanges/1.0.

[Jun Omae]

TracSubversion is documented about supported versions of Subversion. It says that Trac supports Subversion 1.4 - 1.7. We should add Subversion 1.8 to the page.

I agree dropping 1.5 in Trac 1.2. ​Debian squeeze (oldstable), ​Ubuntu 10.04 LTS and ​CentOS 5.10 distribute 1.6. No distributions have 1.5 or early. Previously, CentOS 5.1 - 5.5 distribute 1.4.2.

[Jun Omae]

Added the Subversion 1.8 notes to wiki:TracSubversion@123?action=diff.

[Ryan J Ollos]

I added a statement about Subversion support in TracDev/ApiChanges/1.1.2. Does it may sense to specify the supported optional dependencies there? Could we make a similar statement about supported Git versions?

[Jun Omae]

I noticed unit tests fail with git 1.5.6 and 1.6.6. I've created #11715.

I don't think that it is needed to add supported Git versions to Modified Dependencies in the page because the versions have not changed from Trac 1.0.

[Ryan J Ollos]

Specifics of the section heading aside, it would be useful to document the supported versions in a single document. The release notes may be more appropriate for that.

[Ryan J Ollos]

In [13193], removed the deprecated authname parameter from Environment.get_repository(). Discussed in comment:32:ticket:11605.

[Ryan J Ollos]

Replying to rjollos:

Some thoughts:

• Would it be desirable to have an upgrade step that creates an entry in the [repositories] section of trac.ini, provided the entry doesn't already exist? For example:

…

• Some replacements would seem to be desirable in order to better organize the options (though I would make these changes in a different ticket):
  1. [trac] repository_type → [repositories] default_repository_type

Changes are proposed to be implemented in a slightly different way in #11849.

[Ryan J Ollos]

Replying to rjollos:

At least 3 places in the documentation need to be updated with the removal of [trac] repository_dir. The locations I found grepping the documentation on the trunk are:

• TracEnvironment#SourceCodeRepository
• TracFineGrainedPermissions#TracConfiguration
• TracRepositoryAdmin#Repositories

Documentation edited in:

• 1.1/TracEnvironment@2 and 1.1/TracEnvironment@3
• 1.1/TracFineGrainedPermissions@2
• 1.1/TracRepositoryAdmin@3

[Ryan J Ollos]

Proposed changes in log:rjollos.git:t11703.3:

• If default repository is already configured in the [repositories] section, then [trac] repository_dir is discarded and a message logged at info level. [trac] repository_dir would have been overridden by the configuration in the [repositories] section and therefore ineffective, so I don't see any reason to print a message to the user in the console.
• The default repository in the [repositories] section still uses the default repository type ([trac] repository_type).

[Jun Omae]

I tried to create and upgrade using rjollos.git@t11703.3. It looks good to me.

[Ryan J Ollos]

Thanks for the review. Committed to trunk in [13387]. I'll continue now with #11776, which this ticket was blocking (comment:5:ticket:11776).

[Ryan J Ollos]

Replying to Jun Omae:

Replying to rjollos:

Would it make sense to also have [trac] authz_file as a per repository option?

Yeah. However, I think we should leave this option with no changes. This option accepts path to the Subversion authz file. The Subversion authz file normally has path-based authorization for multiple repositories, Especially before Subversion 1.6.

After Subversion 1.7, new option allows to specify a per repository authz file. See ​AuthzSVNReposRelativeAccessFile.

I did some reading and I think I understand the behavior now. It seems like we should eventually support both global and per-repository access files, so I created #12442.

[Ryan J Ollos]

An empty [trac] repository_dir option was not removed from trac.ini. Fixed in [14871].

[Ryan J Ollos]

Updated warning in trac.admin.console in r16214, merged to trunk in r16216.