Patch testing

Using git bisect for realz.

[tesla:drupal | Thu 17:02:08] $ git bisect good cc7cae5
[tesla:drupal | Thu 17:02:16] $ git bisect bad e0a0b7
Bisecting: 6 revisions left to test after this (roughly 3 steps)
[6cd1a3986615279c1262adb429a4ed3f2f7c7154] Issue #2137599 by segi, Sweetchuck: Incorrect type and default value for the direction of the default language.

Edit: Oops, guess the filenames are ambiguous. It's not a revert of that hash; it's a revert TO that hash. Of everything.

Soooo https://qa.drupal.org/pifr/test/675243 from #12 doesn't have any of the memory fatals, but has other fails. Interesting...

Seems to be like 75% plus fail rate on the bad.

git bisect bad fc04601c
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[14336d94b8da95f2c2f26edb7ffb5c12d58a1212] Issue #2138239 by damiankloip: Use GlobIterator instead of glob.

Ohai, crosspost.

Oh and the interdiff to 2248983-167.

Played a bit with those queries on a site with 350k nodes and 810k revisions by selecting 10 nodes. Some nodes have hundreds of revisions because content is created/updated based on an external system and that can happen many times and creates a new revision each time. However, for all of those, latest revision = default revision as I don't have access to a system which uses forward revisions and has a lot of content. Not sure if the query result would look different then.

I also picked 10 nids where each had several hundred revisions.

The first query took 0.15s on production and ~0.04 after that (query cache is disabled, probably simply because the relevant rows were in memory now). The explain looks like this:

+------+-------------+----------+-------+-------------------+-----------+---------+--------------------------+------+-----------------------+
| id   | select_type | table    | type  | possible_keys     | key       | key_len | ref                      | rows | Extra                 |
+------+-------------+----------+-------+-------------------+-----------+---------+--------------------------+------+-----------------------+
|    1 | SIMPLE      | revision | range | PRIMARY,node__nid | node__nid | 4       | NULL                     | 5065 | Using index condition |
|    1 | SIMPLE      | base     | ref   | node__vid         | node__vid | 5       | ****.revision.vid |    1 |                       |
+------+-------------+----------+-------+-------------------+-----------+---------+--------------------------+------+-----------------------+

The second query takes 0.02-0.04s, probably not quite fair because I was querying for the same nodes and that data was already loaded, the explain:

+------+-------------+------------+-------+-------------------+-----------+---------+--------------------------+------+--------------------------------------------------------+
| id   | select_type | table      | type  | possible_keys     | key       | key_len | ref                      | rows | Extra                                                  |
+------+-------------+------------+-------+-------------------+-----------+---------+--------------------------+------+--------------------------------------------------------+
|    1 | SIMPLE      | revision   | range | PRIMARY,node__nid | node__nid | 4       | NULL                     | 5065 | Using index condition; Using temporary; Using filesort |
|    1 | SIMPLE      | base       | ref   | node__vid         | node__vid | 5       | ***.revision.vid |    1 |                                                        |
|    1 | SIMPLE      | revision_2 | ref   | PRIMARY,node__nid | node__nid | 4       | ***.base.nid     |    1 | Using where; Using index                               |
+------+-------------+------------+-------+-------------------+-----------+---------+--------------------------+------+--------------------------------------------------------+

So while it is not slower to execute, it does use a tempory/filesort, which I imagine could be a problem when loading a larger amount of data?

Does this help?

Edit: More readable explain: https://gist.githubusercontent.com/Berdir/5496a11d0ea30361170d7348095adc...

revision types that WILL create new branches WILL trigger conflict resolution when merging back into the main branch

@amateescu, the conflict resolution will need the revision ID of the entity revision of the main branch, from which the new branch has emerged. This is the original entity, which we'll use to detect whether a change has occurred only in one of the branches (auto merge) or in both of them (conflict). Therefore we have to track that revision ID as well, which will not change in the revisions of the new branch - either as a field on the entity or as metadata on the branch.