Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Andreas Heigl
    @heiglandreas
    Also skipping all the output might make it faster as well...
    Andreas Heigl
    @heiglandreas
    I had an interesting discussion yesterday eventing with Marco Pivetta. The main question was whether it makes sense to split the current SVN repo up into multiple GIT-repos. I know it was me that started with that but he made some good points to not split it up. The main reason being that it makes more complicated than necessary to keep track of changes over multiple repositories.
    So is there actually a reason why we should split it up?
    • It will make a lot of background-stuff easier when its only one repo as there is no need to change working directory all the time while comparing git hashes
    • Everyone with karma can access everything. So far it should is not be necessary to restrict access to certain parts of the repo to certain people
    • It should still be possible to require at least two reviews by code-owners to merge PRs into the repo. And that's even easier when everyone has the same access for smaller languages
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50
    Those are some interesting points πŸ€”
    But touch the Karma system isn’t something that I would do
    Andreas Heigl
    @heiglandreas
    I wouldn't want to touch the karma system!
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50
    πŸ˜‚πŸ˜‚πŸ˜‚
    Andreas Heigl
    @heiglandreas
    I thought i had seen the karma-files lying around somewhere but I can't find it at the moment.
    So can someone with access to them perhaps have a look whether we currently have different karma for the different translations?
    From a Filesystem POV we currently have the docs in SVN subdivided in multiple repos as every language has their own set of trunk, branches and tags folder. That and possibly different karma for the different languages would IMO speak for different GIT-repos for the different languages. But if all have the same karma, I'd rather try to use ONE git-repo for all the names...
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50
    Now I understand your point, would be easier to track/manage things
    Andreas Heigl
    @heiglandreas
    THANKS! I knew I had seen it somewhere!
    But that file shows that access to the different languages is already restricted to different people so my initial approach of moving each language to its own repo seems to be the one to follow. At lesat if we say we "just" want to move docs from SVN to git.
    • Access is already restricted on a language level
    • Tags and Branches are not possible on a level above languages
    Even though diffs currently are possible across languages I have no insight on how often they are actually done
    So how do we want to proceed? One Repo per language or one repo for all?
    Andreas Heigl
    @heiglandreas
    BTW: moved Revision-replacement to PHP: phpdoctest/meta#19
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50
    IMHO we could have multiple repositories, one per language. This way, we could give one this or that access to review, accept and merged PRs
    Benjamin Eberlei
    @beberlei
    hi :-) wanted to drop here to see if i can help
    i have a few necessary doc changes for 7.4 to do, and svn or edit.php.net both annoy me already again ;)
    Nikita Popov
    @nikic
    @beberlei You can submit changes against https://github.com/php/doc-en if you like
    Benjamin Eberlei
    @beberlei
    @nikic are they synced back or is doc-en already live?
    Andreas Heigl
    @heiglandreas
    We're currently in the process of making the toolage work with a
    repo that's constantly pulled from SVN... Using some filter-branch magic. But after a filter branch the connection between SVN and the new head is lost. So I'm currently figuring out how to solve that....
    A y insights into how git svn keeps track of the svn-git commit hash association?
    So far I
    Nikita Popov
    @nikic
    @beberlei It's a read-only mirror, but I have a github webhook to merge PRs into SVN
    Benjamin Eberlei
    @beberlei
    @heiglandreas sorry no clue :( is this an intermediate step before fully migrating? what would be the steps there.
    @nikic i just realized my patch was reverted for good reasons, so the doc chaange is not needed anyways :D
    Nikita Popov
    @nikic
    @heiglandreas Maybe avoid the issue by also keeping the original branch, updating that one and then copying over the commits ... or something?
    Andreas Heigl
    @heiglandreas
    I finally did it! Thanks for letting me work on this for so long. I finally managed to start to understand git a bit deeper :-)
    I added the corresponding files to the meta-repo and added the bash-commands that need to be executed to the wiki.
    All in all what happens is, that the script that replaces the revision-numbers in the files with the corresponding hash from the english repo is executed as tree-filter via git filter-branch. That of course modifies the repository and changes the hashes that are up to now linked to the SVN-revisions. Therefore in a second step these linked hashes need to be replaced in the revmap file of git-svn located in .git/svn/refs/remotes/origin/trunk/.rev_map.[UUID of the SVN-remote from .git/svn/metadata].
    Andreas Heigl
    @heiglandreas
    That took me a while to figure out and adapt appropriately. But that was not everything. Of course the old hashes need to be relpaced with the new ones in several other files for git to understand that the new hashes are now to be used instead of the old ones. greping for old hashes and replacing them in the found files then did the trick. So now we can do a test run on a box that we can set up a cronjob on that can then push the modified repo to the php git server.
    If you have questions: feel free to ask, but expect a low response rate for the next 2 weeks as I'm still on holidays ;-)
    Nikita Popov
    @nikic
    Hey
    I'm a bit out of the loop right now
    Is it right that what is needed right now is just access to the doc git repos on git.php.net for @heiglandreas ?
    @heiglandreas Would it be possible to set up the mirroring for https://github.com/phpdoctest/de to see how things look like?
    Andreas Heigl
    @heiglandreas
    Force-push Access to the documentation-git -repos on git-php.net would be extremely helpfull. As well as either someone that creates the missing repos or karma (and a short howto) for me to do that
    Setting up the mirroring to the phpdoctest-repo would then be a next step. Is there a howto on ... well.. how to do that? ;-)
    But currently I'm still working on the issue with the back-reference. It turned out that rewriting the file is not possible as then SVN is not able to pull in new changes to the file as the file has been modified localy and that modification has not been backported.
    Currently I'm looking into creating one mapping-file that contains the filepath and the hash of the associated file. So instead of having the info in the file itself it would be in one dedicated file within each translation. That would probably also speed up some other tasks as not every file needs to be parsed but I'll see to that later....
    Nikita Popov
    @nikic
    Hrm, I see
    Nikita Popov
    @nikic
    Ugh, is it possibly to work around the whole git svn issue by having one repo (or branch) that has the pristine history created by git svn, and another that has the rewritten one? You would remember at which commit you are in the original, then do the git svn rebase, and then copy over the new commits.
    Andreas Heigl
    @heiglandreas
    Pffftttt... That is an interesting idea as well....