Build: Synchronize .gitignore and svn:ignore

[dmsnell]

The Core git repo and svn repo have mismatched methods for excluding files, which increases the burden of developing in the git repo and in generating the proper commits for the “build repo.”

At the heart of this is the distinction between how git’s .gitignore contains patterns which apply recursively down the directory hierarchy, but svn’s svn:ignore property applies only to the directory on which it’s set.

In [62155], part of the .gitignore was ported into a svn:global-ignores property, but only as much as was required to fix some broken pieces of the 7.0 release process.

This ticket proposes three actions:

• Audit all of the existing ignores in both repos to discover all discrepancies.
• Move all subversion ignores out of per-directory properties and into a single global property.
• Provide a new script or automation to raise issues when the ignore sets diverge.

Related

• This first appeared during the work on #64393.
• A svn:global-ignores property was introduced in [62155]

[jonsurrell]

I started to look at this and noticed the following differences, assuming .gitignore is more up to date:

Index: tests/phpunit/data
===================================================================
--- tests/phpunit/data  (revision 62164)
+++ tests/phpunit/data  (working copy)

Property changes on: tests/phpunit/data
___________________________________________________________________
Modified: svn:ignore
## -1 +1 ##
-.trac-ticket-cache.*
+.trac-ticket-cache*
Index: .
===================================================================
--- .   (revision 62164)
+++ .   (working copy)

Property changes on: .
___________________________________________________________________
Modified: svn:ignore
## -16,8 +16,9 ##
 vendor
 packagehash.txt
 artifacts
+*.tsbuildinfo
 # Files for local environment config
-/docker-compose.override.yml
+docker-compose.override.yml
 .env
 coverage
 

[desrosj]

This came up during the Core Committers meeting during WordCamp Europe. Moving this to the 7.1 release so that this can be addressed.

[dmsnell]

I had Codex write a script to regenerate the SVN rules based on .gitignore, and then asked it to generate a report of existing inconsistencies. This is what it came up with.

Summary of inconsistencies between existing SVN ignore props and .gitignore:

  - Existing SVN has 28 svn:ignore locations plus root svn:global-ignores.
  - Existing root svn:global-ignores is narrow: only config/patch metadata patterns.
  - Audit status counts:
      - covered-by-global: 8
      - covered-by-local: 58
      - covered-by-local-partial: 3
      - covered-by-external: 1
      - missing: 8
      - missing-recursive-path: 1
      - not-representable: 20

  Missing from current SVN ignore behavior:

  /tests/phpunit/data/.trac-ticket-cache*
  /*.tsbuildinfo
  /src/wp-admin/css/colors/*/*.css
  /src/wp-includes/assets/*
  /setup.log
  /src/wp-content/themes/twentytwentytwo/*.min.css
  /src/wp-content/themes/twentytwentyfive/*.min.css
  /docker-compose.override.yml

  Recursive mismatch:

  /tests/performance/**/*.test.results.json

  Git can express that recursively. Current SVN has no matching scoped global/local rule.

  Partially covered recursive rules:

  /src/wp-includes/blocks/**/*.css
  /src/wp-includes/blocks/**/*.js
  /src/wp-includes/blocks/**/*.js.map

  Current SVN has svn:ignore on src/wp-includes/blocks, but svn:ignore is not recursive. These should become subtree svn:global-ignores on src/wp-includes/blocks.

  Bad existing SVN pattern:

  /docker-compose.override.yml

  It exists in root svn:ignore with a leading slash, which does not behave like Git’s root-anchored syntax. The rebuilt rule should be:

  docker-compose.override.yml

  Git-only / not representable:

  - 19 ! negation rules.
  - .svn.

  Those are not converted. In this tree that is acceptable because the negation targets are versioned, and SVN ignores do not hide versioned items.

[afercia]

I just stumbled upon this. After I created a docker-compose.override.yml as specified ​in the README.md and ran the tests, my svn status output is:

$ svn status
?       docker-compose.override.yml
?       tests/phpunit/.phpunit.result.cache
X       tests/phpunit/data/plugins/wordpress-importer

To my understanding, at least these very common cases should be addressed:

In the root folder svn:ignore props, /docker-compose.override.yml should not have the leading slash.

The file .phpunit.result.cache should likely be added to the svn:global-ignores.

[adrianduffell]

This was discussed in today’s bug scrub. With the 7.1 beta just hours away, I will punt this. It looks valuable to pick up in the 7.2 cycle.

[afercia]

Please correct me if I'm wrong but I seem to recall changes to Build/Test Tools can be committed at any time during a release cycle. Cc @annezazu @desrosj

This is a highly desired fix and it would be best to have it addressed soon.

[JeffPaul]

@afercia I believe you're correct, but that's not documented on ​https://make.wordpress.org/core/handbook/tutorials/leading-bug-scrubs/; would you mind adding to that page to help ensure future release squads have that context?

[adrianduffell]

I agree, this would be valuable to have in 7.1. In the bug scrubs, we have been settling on keeping build/test tickets in the cycle if there are signals they can be completed early in the beta schedule. We also need stability in the build tooling as the final release draws nearer.

Is there an appetite here to have this ready before beta 2?

[afercia]

would you mind adding to that page to help ensure future release squads have that context?

I searched for specific references in the release cycle documentation first. It appears we should better clarify this point in the release cycle documentation before adding a reference to the "Leading Bug Scrubs" documentation. If I missed something, please point me to a specific point in the documentation that specifically mentions build tools.

What I found:

Releasing Major Versions > Release Candidate
​https://make.wordpress.org/core/handbook/about/release-cycle/releasing-major-versions/#release-candidate

Restrictions to commits apply to src/. The documentation explicitly states Committers can commit to tests/ at any time. However, there's no mention of changes to build tools. This should be better clarified on this page.

I found indirect references on other posts, for example:

The Path Forward for WordPress 7.0
​https://make.wordpress.org/core/2026/04/02/the-path-forward-for-wordpress-7-0/

where it is stated that Built/Test Tool and/or test coverage improvements are allowed at any time.

Proposal: Make unit test tickets easier to distinguish
​https://make.wordpress.org/core/2024/10/11/proposal-make-unit-test-tickets-easier-to-distinguish/
Where it is stated: unit tests, just like build and test tools, are “non-production code”. That means they can be committed at any time during the WordPress development cycle and do not follow the general milestones-based workflow.

The above references indirectly confirm that, historically, changes to build tools have always been allowed. That should be added to the Release cycle documentation.

However, I would suggest to slightly differentiate the two cases:

• Tests: changes are always allowed at any time.
• Build tools: changes are generically allowed at any time, with a grain of salt. As in: as long as they don't inadvertently modify production code, break continuous integration, or alter localized UI strings during a hard string freeze.

Cc @annezazu @desrosj @milana_cap