[wp-trac] [WordPress Trac] #64393: Change how we include Gutenberg in Core

[WordPress Trac]

#64393: Change how we include Gutenberg in Core
------------------------------+--------------------------
 Reporter:  youknowriad       |       Owner:  youknowriad
     Type:  task (blessed)    |      Status:  reopened
 Priority:  high              |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  blocker           |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+--------------------------

Comment (by dmsnell):

 Happy update here: I have been able to simulate this entire flow and see
 that the version history can be restored for these files through the `svn`
 > `git` bridge, but it’s going to need some manual intervention, including
 help with those who manage that process.

 I think it would be incredibly prudent for us to restore the continuity of
 these files into the repo //before releasing 7.0//, and I would appreciate
 anyone’s help if you work with the system pushing updates from subversion
 into git.

 In [https://github.com/WordPress/wordpress-develop/pull/11064 PR#11064] I
 have added a script and a screencast demonstrating the flow. There were a
 lot of mines in the path to get there, and while I think there’s a chance
 it could be done from the `git` side, and potentially easier so, I wanted
 to be sure that a `svn`-first approach works.

 **Fundamentally**, if we can merge into `trunk` a copy of the deleted
 files whose //merge base// is before
 `22294af4ed3b46f577f42590ba4cc19ca0a93f3f` / [61439], and perform a //non-
 fast-forward merge//, then `git` and all `git` tooling (such as GitHub,
 IDE integrations, Git GUIs) should by default trace the history of these
 files through the merging and no longer represent them as if they were
 brand new today.

 Steps (simplified):
  - from the SVN repo…
     - `svn copy trunk at 61438 branches/restore-required-files` — this
 creates the branch with the fork point //before// the build change.
     - copy the files from a clean checkout of `wordpress/wordpress-
 develop` where `npm ci && npm run build:dev` has already run. this is
 going to copy in the latest version of these built files and create a
 merge conflict that will give us a chance interrupt the auto-merge process
 and “resurrect” the files, as SVN puts it.
     - commit these changes
     - go back to `trunk`
     - `svn merge ^/branches/restore-required-files --accept postpone` will
 start the merge and pause on the conflicts
     - remove the relevant patterns from `.gitignore`
     - since the conflict is a “tree conflict” we can’t just “accept
 theirs” but we can mark the repo as “working copy includes the resolved
 version of the changes.” — `svn resolve --accept working .`
     - `svn add` all of the relevant files that appear in `svn status`
     - `svn commit` to complete the merge and restoration
   - from the `git` repo
     - after the merge is done, perform `git svn fetch --all` to ensure
 that the restoration branch is fetched.  If we leave out this step then
 `git` will linearize the merge and our history //will not connect// to the
 past.
     - `git svn rebase` this should pull in the changes while creating the
 merge commit containing both appropriate parents!

 Obviously the automation synchronizing `git` with `svn` will need to be
 paused during this time otherwise we could get the repo into a messed-up
 state. That’s why I created the simulation in the linked PR, to ensure
 that everything is done the way we expect, and to make it easier to ensure
 that the steps are right, as well as to compare changes to the merge to
 see if they could be better.

 ----

 I would be grateful if anyone who works with the `svn` and `git` repos
 could help me out with this. Once we release 7.0, if the files are not
 restored into that commit then any workflow which skips between official
 releases will hit a wall at 7.0; any attempt to review the total changes
 or examine a changelog will show that these files exist no more, even
 though they are entirely necessary for WordPress to boot. They will appear
 in the ZIP without any clear link back to the source.

 You can review the script and screencast in the linked PR. the code of
 that PR isn’t as important at this moment. Thank you.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64393#comment:174>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform