Re: Re: Moving documentation to git

On Sat, Jun 17, 2017 at 3:04 AM, Maciej Sobaczewski <sobak@php.net> wrote: > I don't fully understand how mentioned suggestion of .git.hashes > would work, but I highly suggest you to start with prototyping it. > Once it would be ready and working, we can go further and adjust > our tooling. > This solution goes like this. We use the SVN sequence to: 1. Track files that need to be updated 2. Generate diffs So any alternative must provide these. But making the sequence (or id) inside a git controlled file is PITA, and this a old road block to migrate from SVN. So, I got thinking: why not storing the sequence/id outside the file? We need only for en/, not for translations or tooling. The idea is, in a en/ local checkout, make revcheck to generate and maintain a ignored .hashs file per directory, to contain the hash commit of each file. I suggest a file with this format: [local file timestamp] [commit hash] [filename] And in translations, to use the hash commit to track the en version of file. So... 1. Track files that need be updated: different hashs in revision tag and .hashs file 2. Generate diffs: between commit hash of file and hash in revision tag. > > Few further problems you will encounter are (just to make you aware): > > 1) There is doc-base which every translation needs to work. Managing > it with git submodules seems like PITA, but I believe there is better > solution. > Separate repositories & separate checkouts for doc-base and languages? This can facilitate the permissions granting latter. > 3) When migrating from SVN $Revision$ to any solution, do not let > outdated files on the translations to lost their status. If file a.xml > in Foo translation is pointing to some other version of the English > tree, please keep it this information - just in the new format. It > happened once or twice in the past that such files were just marked > as EN-Revision: n/a and for many translations it's still a problem > to these days. Remember it's a difference of updating file a few > revisions ahead vs retranslating it from scratch. I'm not sure if > this point is understandable, so let me know if I need to elaborate. > Good catch. To preserve this relation, we need "old" revisions of files in new repository, to have anything to point on. So, on a migration, first is need to scan all the EN-Revision of each file in each translation. And then, for each file and revision, extract that revision from SVN and commit on git, to generate a "old" hash, and finally replace EN-Revision all translations who refer to this file/commit. By last, commit all files in HEAD. (I am assuming that the migration will not be file by file, revision by revision. Otherwise, there only need a map between SVN sequence and commit hashs, to update EN-Revision: of translations) André