Получение целой истории файлов с мерзавцем-p4
Быстрое сравнение данных ответов на 20 тысяч строк данных-
@Alollz (в комментариях)
%timeit df.loc[df.filter(like='Task').applymap(lambda x: 'Drafting' in x).any(1)]
25.2 ms ± 2.09 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
@Sergey Bushmanov
%timeit df[df.Task1.str.contains("Drafting") | df.Task2.str.contains("Drafting") | df.Task3.str.contains("Drafting")]
58.7 ms ± 9.25 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
@ anky_91
%timeit df[df.filter(like='Task').apply(lambda x: x.str.contains('Drafting')).any(axis=1)]
88.6 ms ± 12.5 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
%timeit df[df.astype(str).apply(lambda x: x.str.contains('Drafting')).any(axis=1)]
128 ms ± 14.9 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
@ALollz
%timeit df.loc[df.filter(like='Task').stack().str.split(expand=True).eq('Drafting').any(1).any(level=0)]
290 ms ± 29.9 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
2 ответа
Попробуйте добавить "@all" в путь к файлу. Например, для меня создается репозиторий с одной ревизией:
python /usr/share/doc/git-core/contrib/fast-import/git-p4 clone --destination=master-pom \
//depot/services/master-pom/trunk/...
Эта команда импортировала полную историю:
python /usr/share/doc/git-core/contrib/fast-import/git-p4 clone --destination=master-pom \
//depot/services/master-pom/trunk/...@all
Я попытался использовать пример git-p4, но отказался по нескольким причинам и написал свой собственный насос быстрого импорта. Это было некоторое время назад, поэтому некоторые проблемы могли быть решены сейчас: но у git-p4 были проблемы с большими списками изменений (такими как первоначальное создание ветви) (хотя использование спецификации клиента могло помочь, я не кажется, что я попробовал это) и файлы с модификатором типа файла "+ S" (это Bad And Evil, но мы использовали его). И мой Python-fu не позволил мне решить проблемы, которые у меня были.
РЕДАКТИРОВАТЬ: так как кто-то просил об этом, вот оно.
https://github.com/araqnid/p4utils имеет несколько вещей p4, из которых p4-git-xfer является p4-> мерзавец (односторонний) репликатор. Тем не менее, у него довольно много проблем, поскольку он является главным удобным инструментом, а не реальной частью инфраструктуры.
Начало работы:
p4-git-xfer clone -d $PWD/dictionary.git -n //depot/services/midoffice/dictionary/... \
trunk 'release/*' 'branch/*' \
trunk=master release/*=r* branch/*=dev/*
клонирует этот путь к голому «dictionary.git». Первые аргументы после базового пути - это «спецификации веток», которые сообщают репликатору, где искать ветви под базой. Более поздние (с символами '=') являются «зеркальными спецификациями», которые сообщают репликатору, как создавать локальные ветви из импортированных. Спецификации веток вызывают создание «refs / remotes / p4 / trunk», «refs / remotes / p4 / release / 1.0» и т. Д. Спецификации зеркала заставляют "refs /глав / мастер" отражать "refs / remotes / p4 / trunk", "refs /head / r1.0" отражать "refs / remotes / p4 / release / 1.0" и т. Д. Он был задуман как способ, позволяющий мне выбирать только определенные ветви из тех, которые были реплицированы для распространения в клонах.
Он попытается определить, как создается ветвь, но в любом случае это не совсем верно для Perforce. Кроме того, он вообще не пытается выполнять отслеживание ветвлений: даже слияния целых ветвей не будут записываться как таковые, извините.
После начального клона выполняется p4-git-xfer fetch изнутри реплики git будет выполнять постепенное обновление. Список изменений верхнего уровня взят из marks / p4 внутри git-репо. Это файл меток, который быстро загружается при импорте, поэтому, если вы делаете какую-то изощренную работу, такую как использование filter-branch для перезаписи вещей, будьте осторожны, вам, возможно, придется обновить это тоже.
Это не красиво и имеет некоторую среднюю-среднюю величину. серьезные проблемы; Я использую его в основном для собственного удобства, чтобы изолировать себя от проблем с Perforce, а не как повседневный критический компонент инфраструктуры. Это односторонний подход: я обычно использую скрипт p4-am для применения патчей, созданных git format-patch . Это само по себе работает только в основном, с общим разбросом разбора, проблемами с символами новой строки в конце файла, двоичными изменениями и т. Д.
Я также пытаюсь понять git-p4. К сожалению, не так много документации. Я хотел бы связаться с вами, так как мы, вероятно, можем помочь друг другу.