Re: Moving documentation to git

Hi Andreas, many people before you thought about the same thing, migrating to git is indeed very tempting. As you were told, the biggest issues are structuring the repo(s) and tracking translation status. With SVN and sequential numeric revisions it is quite easy to check whether file is up to date (it's just "greater than" comparision), with Git we need to find workaround. 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. 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. 2) Don't forget about edit.php.net, I think there are many people using it, especially those with SVN access, which are editing files on their local machines and just commit them. I don't have much time these days, but I should be able to help you understanding its inner workings, in case you'll need it. 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. I don't think migrating to Git will be easy task but it surely would bring some new life to the documentation. edit.php.net is an impressive piece of software, but nowadays many people are just used to making GitHub pull requests - and for us it also would be great to review them as such and even validate their correctness with e.g. Travis and configure.php. That's why I also love an idea of edit.php.net submitting pull requests for unauthenticated people. I would suggest you to bring @salathe into this disussion as he is the PHP Manual Editor and has much more actual experience than me. Hannes would be able to clarify some aspects and give his opinion on the topic as well, I think. And, in fact, I just CC'ed them. Good luck! W dniu 14.06.2017 o 17:34, Andreas Heigl pisze:

Hi everybody. Some time ago I requested karma for the documentation (http://news.php.net/php.doc/969386047 and http://news.php.net/php.doc/969386046) and at that time I also mentioned I'd like to help move the docs to git/Github. Time flew by but finally I'd love to give that a go. My idea was as follows: * Move the current trunks of the subfolders of https://svn.php.net/repository/phpdoc/ each to a new git-repository using "git svn" * Move those new git-repositories to GitHub (or somewhere else?) * Make sure that the current manual build-process still works What I don't know yet: * How does that affect edit.php.net - Any insight there is highly appreciated! * How does that affect the automated builds - Also insight here would be highly appreciated. My aim would be to leave as much of the current infrastructure and workflows as they are in the first step and only move the VCS from SVN to git. The improvement would be that it is much easier and more transparent for people without karma to get a documentation change in as it is possible to create a PR on github which is for the most people more intuitive than using edit.php.net A second step could then be to move the automated build-process to a CI-System that would build on merging to master. Or is that a completely futile idea or way to go? Or did I miss some vital parts that need to be considered? (I'm pretty sure I did) Thank you all for your feedback! Cheers Andreas