Edgewall Software

Opened 10 years ago

Last modified 7 years ago

#11703 closed task

Remove deprecated [trac] repository_dir option for configuring repository — at Version 12

Reported by: Ryan J Ollos Owned by:
Priority: normal Milestone: 1.1.3
Component: version control Version:
Severity: normal Keywords:
Cc: Jun Omae Branch:
Release Notes:
API Changes:

Removed deprecated authname parameter from Environment.get_repository().

Internal Changes:

Description

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.

Change History (12)

comment:1 by Ryan J Ollos, 10 years ago

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.

Last edited 10 years ago by Ryan J Ollos (previous) (diff)

in reply to:  1 ; comment:2 by Jun Omae, 10 years ago

Cc: Jun Omae added

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.

  1. [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.

comment:3 by Ryan J Ollos, 10 years ago

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:

in reply to:  2 ; comment:4 by Ryan J Ollos, 10 years ago

Replying to jomae:

  1. [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?

in reply to:  4 comment:5 by Jun Omae, 10 years ago

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.

comment:6 by Ryan J Ollos, 10 years ago

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.

in reply to:  6 comment:7 by Jun Omae, 10 years ago

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.

comment:8 by Jun Omae, 10 years ago

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

comment:9 by Ryan J Ollos, 10 years ago

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?

comment:10 by Jun Omae, 10 years ago

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.

comment:11 by Ryan J Ollos, 10 years ago

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.

Last edited 10 years ago by Ryan J Ollos (previous) (diff)

comment:12 by Ryan J Ollos, 9 years ago

API Changes: modified (diff)

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

Note: See TracTickets for help on using tickets.