Ahh, just saw it in the internals@.
I don't think that this will affect us.
@nikic Aren't we using the git.php.net domain for this migration?
Or only in ways that makes things simpler :)
And then it should be possible to run a cront-task that retrieves the new stuff from SVN, replaces the IDs with the hashes and then pushes to the main repo .
It should be sufficient to run that on an hourly schedule....
it will run the filter on the local copy and then push the altered commits to the upstream repo
Or is Thursday better?
Also.....I'm pissed off at docker. I'm pretty sure that we could make a really nice UX for a local editor tool that does things like automatically jumps to the file you've been editing.
Except that the whole filesystem is just too slow in Docker to be able to watch or handle as many files as there are in the manual.
So.....i'm chucking all of those ideas away, and reverting to some bash scripts that will run on the host machine instead.
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...
@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?
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.
It is commented out on https://github.com/phpdoctest/meta/wiki/Current_Ideas
This bit looks a bit expensive and roundabout: https://github.com/phpdoctest/meta/blob/master/src/Command/ReplaceEnglishRevisionTag.php#L121
Is there a reason to use
sed for this rather than preg_replace, as you're already reading in the file anyway?
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
But touch the Karma system isn’t something that I would do