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

[Yoskaldyr]

Самба мапит x в archive bit уже тыщу лет

на каждом дев сервере ставить самбу??? как по мне это перебор...

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

на винде не нужны, но после мапинга проекта внутрь вагранта/виртуалбокса все атрибуты идут лесом и перестают работать вызовы консольных хелперов на пхп.

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

заливать/тянуть несколько гиг базы все равно придется - она тоже обновляется. И докер насколько я помню для stateless сервисов, а у меня statefull.

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

было бы интересно.

Можно конечно базу в сети держать общую, но тогда сетевые задержки очень сильно сказываются на реальную работу приложения.

Чтобы еще раз разъяснить - это нужно не для нескольких человек, а для одного - просто возможность работать за несколькими компьютерами. Работа не с 1 большим проектом, а с кучей мелких и средних.
Окружение (набор сервисов и данные) должно быть максимально приближенно к клиентскому, т.е. локальные виртуалки подошли бы если бы работал только за одним компом.
И чтобы не дублировать локально, то все виртуалки в сети. Но тогда появляется проблема с медленным синком файлов в сторме на локальный компа и обратно.
И то только периодически, т.к. максимум что приходится синкать - это около до 100 файлов, а это около минуты. Но если меняется вендор, то ждать 15 минут напрягает.
Проблема сторма, в том как он сравнивает файлы (1 поток, проверка на стороне клиента) и как следствие медленная работа для большого количества файлов.
И синкать не много по объему данных 2-3Mb (максимум 10Мб), но много по количеству файлов.
Но если все хранить локально и допустим система и все необходимые службы уже синхронизированы между рабочими местами, то остаются данные которые могут меняться и значительно и минимальный объем с учетом базы это несколько сотен мб. А любой синк данных на сотни мегабайт - это будет значительно дольше 15 минут. Забыл сказать что на одном из рабочих мест интернет - гавно (качать большие объемы не вариант, а тем более заливать).

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

 

[MiksIr]

заливать/тянуть несколько гиг базы все равно придется - она тоже обновляется.

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

а винде не нужны, но после мапинга проекта внутрь вагранта/виртуалбокса все атрибуты идут лесом и перестают работать вызовы консольных хелперов на пхп.

У меня все файлы на винде внутри вагранта - 777, т.е. совершенно нет проблем с консольными хедперами. А вот, например, с маком - есть проблемы, рукам приходится проставлять права скопированным с сетевых дисков файлам.

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

В том то и суть, что никакой разницы нет. Не понимаю, почему ты ее видишь.

 

[Yoskaldyr]

что это твоя основная цель - планы запросов смотреть.

одна из основных задач вообще-то, как раз там где большие базы. Приходится исправлять после умельцев.

 

[MiksIr]

План запросов можно глянуть и на боевой базе. Вообще без проблем.

 

[fixxxer]

Да у него там вообще какой-то колхоз имени ильича, похоже. Какой-нибудь продакшен в стиле "деплоим по ftp" и рабочие станции в стиле "вась, не правь index.php".

Иначе бы не возникало таких идиотских вопросов, мест, где посмотреть план, как минимум два - слейв и ci.

 

[MiksIr]

Да у него там вообще какой-то колхоз имени ильича, похоже. Какой-нибудь продакшен в стиле "деплоим по ftp" и рабочие станции в стиле "вась, не правь index.php".

Иначе бы не возникало таких идиотских вопросов, мест, где посмотреть план, как минимум два - слейв и ci.

Ну я не считаю отсуствие CI или слейва - признаком колхоза, и даже вполне нормально отношусь к git pull на продакшене, но план все же можно посмотреть и на мастере.
Кстати, а как план на CI смотреть? Все же боевая база желательна.

 

[Absinthe]

Все гиты, композеры и прочие вебпаки - запускать локально.

Если у тебя есть возможность успешно запустить composer локально, то практически нет смысла и сервер для разработки использовать.

С виндой это, наверное, сложнее

С виндой это невозможно.

man vagrant

И что я там увижу?
Между прочим, три года использую его, но проблемы с синхронизацией файлов там есть.

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

Симлинки, например.

Самба мапит x в archive bit уже тыщу лет, это работает даже на fat12.

И получаешь тормоза 80 уровня в PhpStorm из-за постоянного индексирования.

 

[MiksIr]

С виндой это невозможно.

Возможно

Между прочим, три года использую его, но проблемы с синхронизацией файлов там есть.

Никаких проблем.

Симлинки, например.

Работают, в винде есть симлинки.

И получаешь тормоза 80 уровня в PhpStorm из-за постоянного индексирования.

Нет никакого "постоянного индексирования"

 

[artoodetoo]

Вероятно речь про индексирование в IDE. На запапленной самбе проекты не держу из-за ооочень тормозного индексирования проекта. А синхронизации не доверяю т.к. были накладки. Нафиг не нужны эти расследования "почему файлы изменились, а ошибка на сайте осталась".

Мой набор: винда+пхпсторм. Проект лежит в виндовой папке, из сторма при сохранении файл выкладывается на виртуальный линкус по sftp, как если бы это был удалённый сервер.
Консоль сигвиновская, git и ssh из сигвина. composer и прочее — всё на винде. Виндовый php для юнит-тестов.

Сигвиновский chmod разруливает биты, но после сохранения из сторма бит x упорно восстанавливается
Борьба с атрибутом x на винде:
http://stackoverflow.com/questions/21691202/how-to-create-file-execute-mode-permissions-in-git-on-windows

 

[Yoskaldyr]

@artoodetoo, а что делать с консольными утилитами и генераторами кода?
И что делать если один проект требует одну верси. пхп, а другой - другую?

 

[MiksIr]

Вероятно речь про индексирование в IDE.

Это один раз когда запуск проекта или, возможно, какие-то глобальные изменения. Зависит, на самом деле, от числа файлов. Около 50к - уже болезненно, но пережить можно.

 

[Absinthe]

Возможно

На невыполнении scripts отвалится. Не все проекты разрабатываются с поддержкой винды.

Никаких проблем.

Кроме невообразимых тормозов?

Работают, в винде есть симлинки.

Есть. Только тот же git, например, их наличие просто игнорирует.

Нет никакого "постоянного индексирования"

Есть. Из-за того, что IDE не может отследить изменения файлов, ей приходится постоянно обходить весь проект.
Если ты не понял, то я имею ввиду случаи, когда проект расположен не на машине, с которой запускается IDE, а с samba и подобных протоколов.

 

[MiksIr]

На невыполнении scripts отвалится. Не все проекты разрабатываются с поддержкой винды.

Говнокод не обсуждаем.

Кроме невообразимых тормозов?

Тормозов нет.

Есть. Только тот же git, например, их наличие просто игнорирует.

Не используйте симлинки в проекте, ваша задача - код писать, а не симлинки.
Симлинки для всяких bin файлов же прекрасно работают.
В принципе и без них можно было бы обойтись, композер умеет решать эту проблему, даже npm можно победить как-то, хотя мне проще было решить вопрос симлинков в виртуалбоксе.

Есть. Из-за того, что IDE не может отследить изменения файлов, ей приходится постоянно обходить весь проект.

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

Если ты не понял, то я имею ввиду случаи, когда проект расположен не на машине, с которой запускается IDE, а с samba и подобных протоколов.

Да, я по такой схеме много лет работал, пока потихоньку на вагрант не стали переводить проекты. И то не все еще. И перкрасно все работает, так что меньше фантазий, больше практики.

 

[Absinthe]

Говнокод не обсуждаем.

Не обсуждаем. Но никто еще и не начинал это делать.

Тормозов нет.

Есть, я ведь даже объяснил, откуда они берутся.
IDE должна получить как-то изменения, и поэтому ей постоянно приходится все переиндексировать

Не используйте симлинки в проекте

Обычно их для ассетов используют, в symfony-проектах с ассетиком.
Проекты большие (сотня человеколет), встречал такое использование в разных компаниях.

ваша задача - код писать, а не симлинки.

Как писать код, если ты не можешь запустить проект, в который тебя взяли?

Случаи изменения файлов на стороне сервера - это исключение.

Мы только что говорили про git на виртуалке.
Смена ветки - явление очень частое, ничего исключительного в этом нет.

И перкрасно все работает, так что меньше фантазий, больше практики.

Я конкретные факты хотя бы привожу, фантазий у меня нет.

 

[MiksIr]

Есть, я ведь даже объяснил, откуда они берутся.
IDE должна получить как-то изменения, и поэтому ей постоянно приходится все переиндексировать

Ты объяснил свои домыслы. Ты даже не различаешь проверку времени изменения и индексирование. Не интересно дискутировать об этом.

Обычно их для ассетов используют, в symfony-проектах с ассетиком.
Проекты большие (сотня человеколет), встречал такое использование в разных компаниях.

Эти линки не комитятся.

Как писать код, если ты не можешь запустить проект, в который тебя взяли?

Проект запускается без проблем, твои слова были про комит гитом. Короткая память?

Мы только что говорили про git на виртуалке.
Смена ветки - явление очень частое, ничего исключительного в этом нет.

Кто говорил? Я нет, гит нужно использовать локально. Впрочем, даже с гитом на виртуалке - проблем нет, меняю иногда. Переиндексации всего проекта не происходит.

Я конкретные факты хотя бы привожу, фантазий у меня нет.

Если не фантазии, то заблуждения. Мне в общем все-равно.
Я свой опыт обозначил, причем самба у меня была не на виртуалке, а в локальной сети, где все должно быть еще хуже.
Впрочем, я не вижу причин для вагранта использовать самбу за исключением одного случая... который тут не упоминался вообще. Да и тогда уж скорее nfs нужно поднимать.

 

[grigori]

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

заливать/тянуть несколько гиг базы все равно придется - она тоже обновляется. И докер насколько я помню для stateless сервисов, а у меня statefull.

Можно конечно базу в сети держать общую, но тогда сетевые задержки очень сильно сказываются на реальную работу приложения.

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

В огороде бузина, а в городе дядька.
Ты хочешь синхронизировать или не хочешь?
Синхронизировать - это по сети. Не синхронизировать - это в vi на проде. Выбирай осторожно. Осторожно, но выбирай. Вчера по 3 или сегодня по 5

Докер - он не для сервисов, он для контейнеров. Любой Stateful разбивается на несколько stateless + хранилище. Например, в тех моих статьях я предложил state (файлы бд, конфиги) положить в shared folder, а все сервисы оставить в stateless-контейнерах. Хочешь синкать базу - синкай контейнер с данными базы, не хочешь - не синкай
Большая база - настрой расчет diff считай и тяни инкрементальный update, тулзы есть.
Не хочешь считать diff, но синкать разницу - работай миграциями.

Окружение (набор сервисов и данные) может быть не приближенно к клиентскому, а идентично.
Сколько у тебя проектов - неважно. Сколько человек - тоже неважно. Один раз надо разобраться и настроить репозиторий. Прямая аналогия с git.

 

[AnrDaemon]

Да, это винда. Да, Cygwin. Да, никаких проблем с аттрибутами я не испытываю. Нет, Самба уже тыщу лет ничего никуда не мапит, ибо скурвилась скатилась до полной виртуализации аттрибутов.
Нет, я не понимаю, зачем на машине разработчика полный дамп БД.

 

[fixxxer]

Ох...

Про самбу я упомянул в этом контексте:

с атрибутами (а именно x атрибут) [...] не видел ни одной утилиты которая умела бы это

Смысла ее использовать с vagrant я тоже вижу 0 целых 0 десятых.
С гитом все настраивается, симлинки просто не надо комитить.
Дамп базы для explain можно поднять где угодно - в любом проекте всегда найдется хотя бы еще один сервер кроме прода (CI, QA etc), туда спокойно влезет еще один контейнер/виртуалка, а если не нашлось не вижу проблем потратить 5 баксов в месяц. В случае с докером - базу на data volume.

grigori вон все правильно сказал.

 

[Yoskaldyr]

После тестов и сравнения удобства unison и rsync остановился на первом, т.к. скорость синхронизации чуть выше и из коробки есть профили синхронизации. т.е. можно настроить 1 раз external tool в PHPStorme и для всех проектов будет работать при условии что есть профиль с именем проекта.

Да велосипед получился, но для моих задач подходит больше всего, т.к. максимально экономит время при работе на моих задачах и работать можно даже с убитого вин планшета через 4g с минимальным временем синка при условии что все сервера в сети.

P.S. сторм + пхп + мускуль - на атоме z8300 - это жесть, не говоря уже о виртуалках

 

[fixxxer]

на атоме z8300

Зачем же себя так мучать?