Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Danack
    @Danack
    So.....i'm chucking all of those ideas away, and reverting to some bash scripts that will run on the host machine instead.
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50
    That sucks. The UX of the current editor is PITA
    Andreas Heigl
    @heiglandreas
    Sorry for being unresponsive. It's been a hard time the last weeks....
    But I managed to get git filter-branch going. Running it on the german translation took about 15 hours, but now all the Revision-IDs are replaced with the corresponding hashes!
    Now I need to automate that process to only run from the last successfull hash on...
    Andreas Heigl
    @heiglandreas
    And then we need to find a machine to run that on via a cron-job.
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50

    @heiglandreas Don't worry, I believe we all are :)

    Good to know that we achieve that!

    @nikic What is missing from your side?

    Nikita Popov
    @nikic
    I think we mainly need input from @salathe, who is running the mirror right now
    @heiglandreas I'm a bit surprised that the filter-branch took 15 hours, that sounds like way too much.
    Unless you're on Windows maybe?
    Andreas Heigl
    @heiglandreas
    Nope. On Linux. But it has to check out every commit and then alter the hashes in all files.
    That takes it's time.
    with ~370 000 commits that takes a minute or two ;-)
    And that was only the first run! Now the next runs shall be incremental and will succeed in a matter of minutes.
    Nikita Popov
    @nikic
    Can you share the code you're using for this?
    Andreas Heigl
    @heiglandreas
    Sure. It was # git filter-branch --tree-filter '/home/aheigl/projects/private/phpdoc/meta/bin/phpdocmeta replaceEnglishRevisionTag -t /home/aheigl/projects/private/phpdoc/en/hash.table'
    Ghost
    @ghost~5a799b6cd73408ce4f8bea50
    Awesome, that Wiki will help us document everything
    Andreas Heigl
    @heiglandreas
    THat's why I started it :joy: I would never have remembered the different steps!
    Nikita Popov
    @nikic
    Is there a reason to use sed for this rather than preg_replace, as you're already reading in the file anyway?
    Andreas Heigl
    @heiglandreas
    I'm only reading the first 1024 bytes to see whether it is necessary to parse the file at all. But sure I could do all of that in PHP.
    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....