Есть ли более быстрая синхронизация файлов Linux - Windows чем в PHPStorm?

[Yoskaldyr]

Так как нет раздела посвященного настройке рабочего окружения и IDE, то пишу здесь.

Заголовок топика не совсем передает смысл задачи, но я хз как по другому назвать.

Работаю под виндой в PHPStorm-e, все дев виртуалки в инете (не в локалке) доступ к файлам по SFTP, т.к. нужен доступ с нескольких компов (периодически то на одном то на другом компе), и т.к. таскать локальные виртуалки между компами не совсем удобно (вагрант и т.п.), то все проекты в сторме настроены по типу "Web server is on remote host, files are accessible via FTP/SFTP/FTPS".
Знаю что не самый оптимальный вариант, но как по другому чтобы не надо было таскать образы виртуалок между машинами - не знаю.

В принципе в таком подходе все устраивает, до тех пор пока не приходится выполнить в консоли на сервере что-то типа композера. Вот тут начинается полная жопа - скачать обновленные зависимости стормом занимает хз сколько времени. И это можно делать 2-мя вариантами (оба треш) или используя встроенный механизм синхронизации (блокировка интерфейса пока сторм скачивает и сравнивает файлы все ничего другого нельзя делать), или тупо скачать всю папку vendor на локальный комп, после чего сторм попытается залить все опять на сервер (это хотя бы в фоне делает и можно продолжать кодить, но тоже занимает дофига и больше времени).

Все варианты расшаривания файлов на сервере и подключения в вин как сетевого диска не совсем подходят, т.к. после изменения файла под вин - слетают линукс атрибуты файлов (сторм под вин при заливке обновленного файла оставляет атрибуты оригинального файла если файл уже был на сервере)
Точно такая же проблема у вин рсинка (слетающие атрибуты), хотя т.к. есть куча портов, может надо другие попробовать...

Поэтому вопрос - как можно решить проблему медленной синхронизации файлов в сторме или как можно изменить воркфлоу (может по другому хранить файлы проекта) и т.д., при условии что к проекту надо иметь доступ с нескольких машин.

P.S. Знаю что кто разрабатывает под вин должны страдать, но не настолько же...

 

[AnrDaemon]

На сервере
~/bin/rsyncd

#!/bin/sh
logger -is -- Running custom rsync $USER $*
/usr/bin/rsync --config="$HOME/.rsyncd" "$@"

~/.rsyncd

address 127.0.0.1
uid = <юзер>
use chroot = no
refuse options = no-iconv

[Documents]
    path = <хомяк>/Documents
    comment = Documents
    read only = no
    charset = UTF-8
    filter = - .svn/*** - CVS/***
    incoming chmod = Dg+s,o=

Синкать например так:

#!/bin/sh
#
export LANG=$(locale -uU)
test -r "$HOME/.ssh_agent" && . "$HOME/.ssh_agent"
/bin/rsync -Fxtcrv --iconv=. --rsh="ssh" --rsync-path='$HOME/bin/rsyncd' -- "$HOME/Documents/" "anrdaemon@Daemon1::Documents/" 2>> "$HOME/rsync-errors-$(date +%F).log" | tee "$HOME/rsync-Documents-$(date +%F).log" | grep -vE "\/$"

Ничего с сервера не скачивается, передаются только изменённые файлы. Права выставляет сервер. При условии, что ACL правильно выставлены.

 

[Yoskaldyr]

@AnrDaemon, Точно под вин? Если да то каким именно порт использовался? Потому что я не смог заставить cwRsync не сбрасывать x атрибут на сервере при модификации на локалке (да и вообще у cygwin-а костыльный подход к линукс атрибутам).

 

[WMix]

Я просто маунтю папку src и tests в vm. но жопа с линками, когда вендор синхронизируешь обратно

 

[fixxxer]

Не буду рассказывать, что так делать не надо - приходилось разок в таких условиях работать, с ремотным девел-сервером: на лишние лицензии на используемый там хитрый серверный софт никто не хотел раскошеливаться.

https://github.com/DmitryKoterov/dklab_realsync

В принципе обертка вокруг того же rsync-а, только плюс еще fswatch.

Только аккуратно - он синхронизирует ровно в одну сторону - с локалки на сервер, включая удаление. Все гиты, композеры и прочие вебпаки - запускать локально. С виндой это, наверное, сложнее, но уж где-то ты должен страдать со своей виндой

 

[Yoskaldyr]

Я просто маунтю папку src и tests в vm. но жопа с линками, когда вендор синхронизируешь обратно

У меня проблема не только с линками но и с атрибутами (а именно x атрибут) - все херится, т.к. нет в винде линуксовых атрибутов, хотя технически их можно хранить в extended атрибутах ntfs, но не видел ни одной утилиты которая умела бы это.

@fixxxer, Я понимаю что не надо, но как сделать возможность работы с нескольких компов над одним проектом? не для нескольких человек (тут да у каждого своя песочница и каждый свои изменения пишет в реп в своей ветке а потом код ревью и мерж), а именно для одного - таскать виртуалку на флешке - это проходили и флешки дохли и очень легко забыть в одном из компов. Загружать в облако всю виртуалку - как-то бредово, каждый раз ждать по полчаса пока скачается образ в начале работы и в конце когда зальется - приятного мало.

 

[Yoskaldyr]

А и еще - основная проблема в доступе к песочнице, что важен не только код, но и данные, которых довольно таки много. Например, чисто тестовыми данными в базе не обойтись - нужны полные дампы, для объективной оценки скорости выполнения запросов (в условиях наиболее приближенных к продакшену)

 

[fixxxer]

man vagrant

данные, которых довольно таки много

И нафига они всем одинаковые? Слил один раз, потом миграции накладывать и сидить новое.

таскать виртуалку на флешке

Посмотрел на календарь. Не, вроде 2016й.

 

[WMix]

ну если проблема ставь линух а если спросят почему, гри

 

[Yoskaldyr]

man vagrant
И нафига они всем одинаковые? Слил один раз, потом миграции накладывать и сидить новое.
Посмотрел на календарь. Не, вроде 2016й.

Нужен именно реальный дамп базы с данными (на несколько гигов), чтобы с бОльшей вероятностью знать план выполнения запросов на реальных данных (под нагрузкой по мере заполнения пула может быть и другой, но это редко)

 

[fixxxer]

И на кой половой орган это на машине разработчика? Гоняйте такие тесты на CI.

 

[Yoskaldyr]

И на кой половой орган это на машине разработчика? Гоняйте такие тесты на CI.

Это не для тестов. Мне надо знать как отработает запрос на реальных данных, в момент написания кода, а не проверять что получилось на этапе тестирования. Когда простой запрос - нет проблем с 99% можно предсказать план его выполнения, но сложный запрос можно написать несколькими вариантами и как он отработает хотелось бы знать заранее.

dklab_realsync не подходит, т.к. мне надо все с точностью наоборот - быстрый синк с сервера на локал и не как filewatch а просто одной командой, которую можно выполнить при открытии проекта.

Скорее всего остановлюсь или на rsync-е или на lftp и добавлю в экстернал тулзы сторма и добавлю в стартап при открытии проекта.

Может еще добавлю setfac/getfacl, не знаю.

 

[fixxxer]

ну сходил на сервер по ssh, погонял свои explain analyze. остальное то тут каким боком?

 

[Yoskaldyr]

ну сходил на сервер по ssh, погонял свои explain analyze. остальное то тут каким боком?

На боевой сервер тестировать update????

 

[fixxxer]

Где я сказал "на боевой"?

 

[Yoskaldyr]

@fixxxer, С таким подходом будет >3 настроенных сервера и >2 отдельных рабочих места.

Я наверное не правильно поставил вопрос. Мне надо одно рабочее место просто продублирвоанное на 2-х или 3-х компах. С минимальным временем синхронизации.

Локальные виртуалки поэтому не подходят (вагрант в том числе) - долго.
Да вообще в винде вагрант еще то убожество (проблемы не вагранта а маппинга в виндовую фс, где нет линукс атрибутов). Ставить пхп под вин тоже полное извращение.

Поэтому я уже понял, что придется или костыли делать или страдать...

 

[fixxxer]

Проблемы как в 2003-м году, правда. Сервер.
Запустил еще один lxc/докер/kvm/.. с постгресом да и все.

 

[MiksIr]

Да вообще в винде вагрант еще то убожество (проблемы не вагранта а маппинга в виндовую фс, где нет линукс атрибутов).

На они тебе там нужны?

 

[fixxxer]

с атрибутами (а именно x атрибут) - все херится, т.к. нет в винде линуксовых атрибутов, хотя технически их можно хранить в extended атрибутах ntfs, но не видел ни одной утилиты которая умела бы это

Пффф... Самба мапит x в archive bit уже тыщу лет, это работает даже на fat12. Не знаю как в vagrant, может и никак. Но зачем оно там? Настроить гит, чтобы не трогал, и все.

 

[grigori]

но как по другому чтобы не надо было таскать образы виртуалок между машинами - не знаю.

контейнеры с репозиторием на виртуалке - так же, как git, только весь стек целиком, и тянет, соответственно, только слои с обновлениями

в случае с докером - создать пачку контейнеров, связать их через compose, на виртуалке поднять registry и pull/push
если будет интерес у публики - могу дописать в серию статью о том, как это сделать

это особенно удобно в крупном проекте с кучей приложений и зависимостями, пытаюсь реализовать