| /dokuwiki/inc/ChangeLog/ |
| H A D | MediaChangeLog.php | 01e8d739c8b53aeb1d0a653331d65eb1f8394002 Sat Apr 25 15:30:23 UTC 2026 Andreas Gohr <andi@splitbrain.org> refactor(changelog): persist external-edit detection on first read
This addresses the flaky test that makes tests randomly fail (mostly on
windows runners).
The flake in common_saveWikiText_test::test_savesequence5 came from
this line in ChangeLog::getCurrentRevisionInfo():
'date' => max($lastRev + 1, time() - 1)
The synthesized "external delete" entry was kept in memory only and
only persisted later, when saveWikiText next called detectExternalEdit.
That meant the formula was evaluated twice on different ChangeLog
instances — once during the test's inspection, and again during the
following saveWikiText — and the two evaluations could pick different
seconds depending on how long the surrounding I/O took. The test
cached the first result in $expectExternal and asserted it against the
on-disk entry written during the second call. On the slower Windows
runner the second call sometimes crossed a second boundary, producing
the off-by-one date mismatch.
The questions I had was, why are we persisting external file deletions
(or edits) only when a page is saved when we are obviously already
detecting it earlier during the changelog read already?
Instead of recording the external delete at the time a new page is
written, it makes sense to record it as soon as we detect it (when the
changelog is requested by a user or a bot). This will make the recoded
timestamp closer to the actual deletion.
This patch refactors the changelog accordingly, but still tries to be
minimal invasive (I think the changelog handling would need much more
refactoring, but that's beyond the scope of this change).
To enable proper locking (when logging an external edit and copying
the attic file), locking had to be moved to the Changelog class,
duplicating some code of io_saveFile.
PageFile::detectExternalEdit() and the deprecated procedural wrapper
detectExternalEdit() in inc/common.php are removed. A codesearch.dokuwiki.org
check confirmed no plugin calls the method directly; the only external
caller of the procedural function is the farmsync plugin, which needs
a parallel update.
|
| H A D | PageChangeLog.php | 01e8d739c8b53aeb1d0a653331d65eb1f8394002 Sat Apr 25 15:30:23 UTC 2026 Andreas Gohr <andi@splitbrain.org> refactor(changelog): persist external-edit detection on first read
This addresses the flaky test that makes tests randomly fail (mostly on
windows runners).
The flake in common_saveWikiText_test::test_savesequence5 came from
this line in ChangeLog::getCurrentRevisionInfo():
'date' => max($lastRev + 1, time() - 1)
The synthesized "external delete" entry was kept in memory only and
only persisted later, when saveWikiText next called detectExternalEdit.
That meant the formula was evaluated twice on different ChangeLog
instances — once during the test's inspection, and again during the
following saveWikiText — and the two evaluations could pick different
seconds depending on how long the surrounding I/O took. The test
cached the first result in $expectExternal and asserted it against the
on-disk entry written during the second call. On the slower Windows
runner the second call sometimes crossed a second boundary, producing
the off-by-one date mismatch.
The questions I had was, why are we persisting external file deletions
(or edits) only when a page is saved when we are obviously already
detecting it earlier during the changelog read already?
Instead of recording the external delete at the time a new page is
written, it makes sense to record it as soon as we detect it (when the
changelog is requested by a user or a bot). This will make the recoded
timestamp closer to the actual deletion.
This patch refactors the changelog accordingly, but still tries to be
minimal invasive (I think the changelog handling would need much more
refactoring, but that's beyond the scope of this change).
To enable proper locking (when logging an external edit and copying
the attic file), locking had to be moved to the Changelog class,
duplicating some code of io_saveFile.
PageFile::detectExternalEdit() and the deprecated procedural wrapper
detectExternalEdit() in inc/common.php are removed. A codesearch.dokuwiki.org
check confirmed no plugin calls the method directly; the only external
caller of the procedural function is the farmsync plugin, which needs
a parallel update.
|
| H A D | ChangeLog.php | 01e8d739c8b53aeb1d0a653331d65eb1f8394002 Sat Apr 25 15:30:23 UTC 2026 Andreas Gohr <andi@splitbrain.org> refactor(changelog): persist external-edit detection on first read
This addresses the flaky test that makes tests randomly fail (mostly on
windows runners).
The flake in common_saveWikiText_test::test_savesequence5 came from
this line in ChangeLog::getCurrentRevisionInfo():
'date' => max($lastRev + 1, time() - 1)
The synthesized "external delete" entry was kept in memory only and
only persisted later, when saveWikiText next called detectExternalEdit.
That meant the formula was evaluated twice on different ChangeLog
instances — once during the test's inspection, and again during the
following saveWikiText — and the two evaluations could pick different
seconds depending on how long the surrounding I/O took. The test
cached the first result in $expectExternal and asserted it against the
on-disk entry written during the second call. On the slower Windows
runner the second call sometimes crossed a second boundary, producing
the off-by-one date mismatch.
The questions I had was, why are we persisting external file deletions
(or edits) only when a page is saved when we are obviously already
detecting it earlier during the changelog read already?
Instead of recording the external delete at the time a new page is
written, it makes sense to record it as soon as we detect it (when the
changelog is requested by a user or a bot). This will make the recoded
timestamp closer to the actual deletion.
This patch refactors the changelog accordingly, but still tries to be
minimal invasive (I think the changelog handling would need much more
refactoring, but that's beyond the scope of this change).
To enable proper locking (when logging an external edit and copying
the attic file), locking had to be moved to the Changelog class,
duplicating some code of io_saveFile.
PageFile::detectExternalEdit() and the deprecated procedural wrapper
detectExternalEdit() in inc/common.php are removed. A codesearch.dokuwiki.org
check confirmed no plugin calls the method directly; the only external
caller of the procedural function is the farmsync plugin, which needs
a parallel update.
|
| /dokuwiki/inc/File/ |
| H A D | PageFile.php | 01e8d739c8b53aeb1d0a653331d65eb1f8394002 Sat Apr 25 15:30:23 UTC 2026 Andreas Gohr <andi@splitbrain.org> refactor(changelog): persist external-edit detection on first read
This addresses the flaky test that makes tests randomly fail (mostly on
windows runners).
The flake in common_saveWikiText_test::test_savesequence5 came from
this line in ChangeLog::getCurrentRevisionInfo():
'date' => max($lastRev + 1, time() - 1)
The synthesized "external delete" entry was kept in memory only and
only persisted later, when saveWikiText next called detectExternalEdit.
That meant the formula was evaluated twice on different ChangeLog
instances — once during the test's inspection, and again during the
following saveWikiText — and the two evaluations could pick different
seconds depending on how long the surrounding I/O took. The test
cached the first result in $expectExternal and asserted it against the
on-disk entry written during the second call. On the slower Windows
runner the second call sometimes crossed a second boundary, producing
the off-by-one date mismatch.
The questions I had was, why are we persisting external file deletions
(or edits) only when a page is saved when we are obviously already
detecting it earlier during the changelog read already?
Instead of recording the external delete at the time a new page is
written, it makes sense to record it as soon as we detect it (when the
changelog is requested by a user or a bot). This will make the recoded
timestamp closer to the actual deletion.
This patch refactors the changelog accordingly, but still tries to be
minimal invasive (I think the changelog handling would need much more
refactoring, but that's beyond the scope of this change).
To enable proper locking (when logging an external edit and copying
the attic file), locking had to be moved to the Changelog class,
duplicating some code of io_saveFile.
PageFile::detectExternalEdit() and the deprecated procedural wrapper
detectExternalEdit() in inc/common.php are removed. A codesearch.dokuwiki.org
check confirmed no plugin calls the method directly; the only external
caller of the procedural function is the farmsync plugin, which needs
a parallel update.
|
| /dokuwiki/_test/tests/inc/ |
| H A D | changelog_getrelativerevision.test.php | 01e8d739c8b53aeb1d0a653331d65eb1f8394002 Sat Apr 25 15:30:23 UTC 2026 Andreas Gohr <andi@splitbrain.org> refactor(changelog): persist external-edit detection on first read
This addresses the flaky test that makes tests randomly fail (mostly on
windows runners).
The flake in common_saveWikiText_test::test_savesequence5 came from
this line in ChangeLog::getCurrentRevisionInfo():
'date' => max($lastRev + 1, time() - 1)
The synthesized "external delete" entry was kept in memory only and
only persisted later, when saveWikiText next called detectExternalEdit.
That meant the formula was evaluated twice on different ChangeLog
instances — once during the test's inspection, and again during the
following saveWikiText — and the two evaluations could pick different
seconds depending on how long the surrounding I/O took. The test
cached the first result in $expectExternal and asserted it against the
on-disk entry written during the second call. On the slower Windows
runner the second call sometimes crossed a second boundary, producing
the off-by-one date mismatch.
The questions I had was, why are we persisting external file deletions
(or edits) only when a page is saved when we are obviously already
detecting it earlier during the changelog read already?
Instead of recording the external delete at the time a new page is
written, it makes sense to record it as soon as we detect it (when the
changelog is requested by a user or a bot). This will make the recoded
timestamp closer to the actual deletion.
This patch refactors the changelog accordingly, but still tries to be
minimal invasive (I think the changelog handling would need much more
refactoring, but that's beyond the scope of this change).
To enable proper locking (when logging an external edit and copying
the attic file), locking had to be moved to the Changelog class,
duplicating some code of io_saveFile.
PageFile::detectExternalEdit() and the deprecated procedural wrapper
detectExternalEdit() in inc/common.php are removed. A codesearch.dokuwiki.org
check confirmed no plugin calls the method directly; the only external
caller of the procedural function is the farmsync plugin, which needs
a parallel update.
|
| H A D | common_saveWikiText.test.php | 01e8d739c8b53aeb1d0a653331d65eb1f8394002 Sat Apr 25 15:30:23 UTC 2026 Andreas Gohr <andi@splitbrain.org> refactor(changelog): persist external-edit detection on first read
This addresses the flaky test that makes tests randomly fail (mostly on
windows runners).
The flake in common_saveWikiText_test::test_savesequence5 came from
this line in ChangeLog::getCurrentRevisionInfo():
'date' => max($lastRev + 1, time() - 1)
The synthesized "external delete" entry was kept in memory only and
only persisted later, when saveWikiText next called detectExternalEdit.
That meant the formula was evaluated twice on different ChangeLog
instances — once during the test's inspection, and again during the
following saveWikiText — and the two evaluations could pick different
seconds depending on how long the surrounding I/O took. The test
cached the first result in $expectExternal and asserted it against the
on-disk entry written during the second call. On the slower Windows
runner the second call sometimes crossed a second boundary, producing
the off-by-one date mismatch.
The questions I had was, why are we persisting external file deletions
(or edits) only when a page is saved when we are obviously already
detecting it earlier during the changelog read already?
Instead of recording the external delete at the time a new page is
written, it makes sense to record it as soon as we detect it (when the
changelog is requested by a user or a bot). This will make the recoded
timestamp closer to the actual deletion.
This patch refactors the changelog accordingly, but still tries to be
minimal invasive (I think the changelog handling would need much more
refactoring, but that's beyond the scope of this change).
To enable proper locking (when logging an external edit and copying
the attic file), locking had to be moved to the Changelog class,
duplicating some code of io_saveFile.
PageFile::detectExternalEdit() and the deprecated procedural wrapper
detectExternalEdit() in inc/common.php are removed. A codesearch.dokuwiki.org
check confirmed no plugin calls the method directly; the only external
caller of the procedural function is the farmsync plugin, which needs
a parallel update.
|
| /dokuwiki/inc/ |
| H A D | common.php | 01e8d739c8b53aeb1d0a653331d65eb1f8394002 Sat Apr 25 15:30:23 UTC 2026 Andreas Gohr <andi@splitbrain.org> refactor(changelog): persist external-edit detection on first read
This addresses the flaky test that makes tests randomly fail (mostly on
windows runners).
The flake in common_saveWikiText_test::test_savesequence5 came from
this line in ChangeLog::getCurrentRevisionInfo():
'date' => max($lastRev + 1, time() - 1)
The synthesized "external delete" entry was kept in memory only and
only persisted later, when saveWikiText next called detectExternalEdit.
That meant the formula was evaluated twice on different ChangeLog
instances — once during the test's inspection, and again during the
following saveWikiText — and the two evaluations could pick different
seconds depending on how long the surrounding I/O took. The test
cached the first result in $expectExternal and asserted it against the
on-disk entry written during the second call. On the slower Windows
runner the second call sometimes crossed a second boundary, producing
the off-by-one date mismatch.
The questions I had was, why are we persisting external file deletions
(or edits) only when a page is saved when we are obviously already
detecting it earlier during the changelog read already?
Instead of recording the external delete at the time a new page is
written, it makes sense to record it as soon as we detect it (when the
changelog is requested by a user or a bot). This will make the recoded
timestamp closer to the actual deletion.
This patch refactors the changelog accordingly, but still tries to be
minimal invasive (I think the changelog handling would need much more
refactoring, but that's beyond the scope of this change).
To enable proper locking (when logging an external edit and copying
the attic file), locking had to be moved to the Changelog class,
duplicating some code of io_saveFile.
PageFile::detectExternalEdit() and the deprecated procedural wrapper
detectExternalEdit() in inc/common.php are removed. A codesearch.dokuwiki.org
check confirmed no plugin calls the method directly; the only external
caller of the procedural function is the farmsync plugin, which needs
a parallel update.
|