0,1
рейтинг
3 марта 2012 в 21:37

Разработка → RealSync — односторонняя синхронизация исходников в реальном времени для веб-разработчиков

Представляю общественности утилиту RealSync (GPL). Ее призвание — облегчить работу тех, кто периодически мучается от лагов сетевой папки Samba при поиске/редактировании файлов веб-проекта. Идея RealSync в том, что вы теперь работаете с файлами сайта на локальной машине в привычной IDE, а результат, как и прежде, смотрите на удаленном разработческом веб-сервере, куда RealSync копирует изменения в реальном времени. В результате вы можете, например, запустить поиск по всем файлам в IDE — они же локальные, а не подключены через сетевую папку по Samba, так что поиск работает очень быстро; при этом ваш Ctrl+S продолжает попадать на сервер моментально, как и при работе через сетевую папку.

RealSync — утилита для Windows, MacOS и Linux, позволяющая в реальном времени содержать на удаленном сервере точную копию файлов (например, скриптов на PHP, Python, Ruby и др.) из папки на вашем локальном компьютере, даже в условиях плохой связи, когда вы работаете из дома. Все изменения, производимые в локальной папке, попадают на сервер практически моментально (задержка около 0.2 с), независимо от того, сколько этих изменений и каким именно образом они были внесены (хоть через IDE, хоть через Блокнот или Far).

Главное отличие RealSync от аналогов — в том, что он крайне устойчив к нестабильности интернет-соединения, реконнектам и тайм-аутам. При этом используется SSH-соединение, доступ через которое конфигурируется автоматически при первом запуске утилиты (т.е. не нужно возиться с ключами — настройка производится в интерактивном режиме).

Фактически, случайно «убить» RealSync почти невозможно. Вы можете держать его постоянно свернутым в трее и забыть про его существование (CPU он почти не ест). Если утилита видит, что соединение разорвалось на длительный срок, автоматически запускается знакомый многим алгоритм RSYNC для быстрого копирования большого количества различий. В режиме же реального времени применяется собственный протокол поверх SSH, чтобы при нажатии Ctrl+S в редакторе вы сразу же видели изменения на сервере. Передача файла сопровождается приятным «треньканьем» (отключаемым при необходимости в конфиге), а временная потеря связи — покраснением иконки (когда связь восстановится, иконка обратно станет серой, а RealSync «догонит» накопившиеся изменения).

И зачем этот велосипед, когда есть Samba или Денвер или XAMPP?


Вообще говоря, существует несколько способов вести разработку веб-скриптов. Первый способ — использовать локальный веб-сервер. У данного метода есть как масса преимуществ (больший контроль, улучшение переносимости и кроссплатформенности и т.д.), так и масса недостатков, как то: потенциальное отличие конфигурации локального сервера от конфигурации дев- и продакшен-зон, необходимость либо следить за синхронностью локальной SQL-базы, либо ждать, пока тормозит доступ к единой дев-базе по интернету и т.д. Мы не будем в данной статье рассматривать этот метод, хотя он, безусловно, имеет право на жизнь (и, как минимум, применяется 1 миллионом зарегистрированных пользователей того же Денвера).

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

Использование удаленной папки для веб-разработки


К директории на удаленном сервере нужно ведь как-то «доступаться». В наиболее распространенном случае ее просто подключают в качестве сетевой папки на локальную машину по Samba. Этот способ имеет сразу несколько неудобств:
  1. Для сносной скорости работы вы должны находиться в той же локальной сети, что и сервер.
  2. Но даже в этом случае вам будет довольно затруднительно запустить поиск по всем файлам большого проекта в IDE — слишком большая задержка.
  3. В случае разрыва соединения (или же вы не дай бог работаете из дома через интернет) — будьте готовы к странным эффектам и неприятным лагам.
Я знаю многих людей, которые для обхода неудобства (2) заходят по SSH на сервер и в консоли используют grep для поиска по файлам, причем сами работают в IDE. Мне это кажется верхом неудобства. Тем более что в phpStorm, например, поиск по всем локальным файлам даже очень большого проекта работает ощутимо быстрее grep-а и занимает 1-2 секунды (как они этого добились — для меня загадка; видимо, индексируют что-то заранее). Лично я постоянно и с комфортом пользуюсь поиском в phpStorm по локальным файлам — в среднем раз по 50 в день.
Есть еще, конечно, любители работать в VIM в SSH-консоли прямо на сервере; я их уважаю, но вряд ли когда примкну к их лагерю: все-таки удобства, предоставляемые хорошей графической IDE, для меня перевешивают.

По большему счету RealSync — это решение проблемы скорости работы IDE


Итак, чтобы решить проблему скорости поиска, нужно хранить исходники на локальном диске и искать уже по ним. И сразу же возникает вопрос, как исходники попадут на удаленный веб-сервер при нажатии Ctrl+S. Тут возможны несколько вариантов.
  1. Почти все IDE поддерживают передачу измененного файла (по FTP или SSH) на удаленный сервер при нажатии Ctrl+S. Но только здесь две проблемы. Во-первых, вы не сможете изменять файлы «мимо» IDE (например, сделать git pull из командной строки на локальной машине). Во-вторых, если вы на несколько дней исчезнете из реальности интернета, а потом вернетесь с измененными файлами, IDE уже не сможет определить, какие файлы изменились (особенно если они еще случайно и на сервере поменялись почему-то независимо от вас), и в лучшем случае начнет полное копирование, что займет полчаса.
  2. Запустить в вечном цикле RSYNC. Это более-менее работает, когда проект не очень большой, когда интернет хороший и когда вы сидите НЕ на Windows (в Windows RSYNC весьма медленный при запуске). Во всех остальных случаях будьте готовы к 2-3-секундным задержкам.
  3. Использовать специальную утилиту синхронизации, такую как RealSync, Unison, WinSCP и т.д.
RealSync задумывался как инструмент, обеспечивающий устойчивую работу в условиях плохой связи и не требующий внимания от программиста («запустил и забыл»). Именно таким он и получился, в отличие от многочисленных аналогов.

А если мне нужна двусторонняя синхронизация?


Это очень популярный вопрос, связанный с тем, что RealSync всегда затирает любые изменения, производимые напрямую в папке на сервере (если не сразу, так при очередном реконнекте точно). Только изменения в локальной папке имеют смысл и приоритет.

Но давайте задумаемся, зачем может понадобиться двусторонняя синхронизация?
  • Вы хотите работать, например, с Git в консоли на сервере? Но зачем? Ведь можно поставить Git на свою машину и пользоваться всеми преимуществами локальной работы и разными GUI для Git.
  • Ваши скрипты пишут в какую-то локальную папку в рамках директории документов? Добавьте эту папку в исключения RealSync (это делается легко, одной строчкой в конфиге или при самом первом запуске). К тому же делать директорию документов доступной для записи скриптами — это антипаттерн.
  • Вы работаете на ноутбуке дома и на другом десктопе — на работе и хотите синхронизировать файлы через папку веб-сервера? Но ведь веб-сервер — это не средства синхронизации и контроля версий. Используйте лучше Dropbox или коммитьте в систему контроля версий.
  • Вы активно используете симлинки в рабочей копии на сервере? Ну… а не пробовали перестать их использовать, это как минимум упростит поддержку и развертывание в будущем?
В целом нужно понимать, что RealSync — это не синхронизатор, это репликатор. Если перестать воспринимать папку на веб-сервере как нечто самостоятельное, а считать ее просто автоматическим «зеркалом» и перестать ходить в нее руками по SSH (действительно, зачем это делать?), все встает на свои места. И в большинстве случаев оказывается, что двусторонняя синхронизация просто не нужна (но если вы по-прежнему считаете иначе, пользуйтесь Unison-ом — если он у вас приживется, конечно.)

Установка RealSync и первый запуск


Все достаточно просто: сначала нужно скачать RealSync и скопировать его куда-нибудь, а затем где-то (в Автозагрузке или на Рабочем столе) разместить ярлык со следующей командной строкой:

"C:/Program Files/dklab_realsync/realsync.exe" ПолныйПутьДоВашейПапкиИсходников
    - или для MacOS и Linux -
perl /opt/dklab_realsync/realsync ПолныйПутьДоВашейПапкиИсходников

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


Если вы уже имеете беспарольный доступ к серверу по SSH-ключу, пароль не будет запрашиваться вообще, даже в первый раз. Если еще не имеете — RealSync сам сгенерирует открытый+закрытый ключ, отрытый положится на сервер, а закрытый — в вашу домашнюю директорию на локальной машине (в специальную папку, которую воспринимает RealSync).
Остальные настройки конфигурации запишутся в файл ПолныйПутьДоВашейПапкиИсходников/.realsync, так что при следующем запуске уже никаких вопросов задано не будет, а просто запустится синхронизация, и программа свернется в трей (для Windows).

Теперь можно править любые исходники и убеждаться, что они моментально попадают на сервер. Если кликнуть на иконку запущенного RealSync в трее, то процесс работы можно наблюдать примерно вот в таком окне:


Дистрибутив RealSync для Windows является самодостаточным: он уже включает в себя RSYNC, SSH, мини-версию Perl и другие необходимые утилиты, так что вам достаточно будет просто запускать realsync.exe и ни о чем этом не думать. В MacOS и Linux же все эти утилиты, как правило, уже имеются в системе, поэтому они и используются.
Итак, RealSync висит в трее, вы его никогда не выключаете, поэтому у вас возникает полная иллюзия, что вы работаете на локальной машине с удаленной папкой. При этом вы имеете все преимущества производительности локального поиска и работы с IDE. Вот это и была цель разработки RealSync.

Буду рад, если утилита сделает еще чью-нибудь повседневную работу легче. Комментарии приветствуются. Проект на GitHub-e: dklab_realsync.
Дмитрий Котеров @DmitryKoterov
карма
385,2
рейтинг 0,1
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (170)

  • +3
    sparkleshare — обёртка к Git, благодаря чему есть не только полный контроль над данными (в обе стороны), но и система отслеживания версий с уведомлениями об изменениях.

    В целом нужно понимать, что RealSync — это не синхронизатор, это репликатор
    вот это я не понимаю, т.е. понимаю что — но не понимаю зачем
    • 0
      У sparkleshare и RealSync совершенно разные предназначения. RealSync — это просто решение проблем лагов Samba (когда проект большой и хочется запустить поиск по файлам, например, по Samba это будет происходить безумно медленно). Т.е. своего рода способ организации сетевой папки, доступ к которой происходит только с вашего компьютера. Отслеживание версий и изменений здесь совершенно ни при чем — для этого есть Git.
      • +1
        а ещё git после push может выполнять с файлами что угодно, в том числе и копировать куда захочется ^_^

        хотя может те кто все изменения делает прямо на сервере будут рады RealSync
        • +1
          Например, вы пишете код, потом видите Parse error в браузере на ДЕВ-СЕРВЕРЕ (при работе с сайтом на PHP). Идете в редакторе, правите 1 букву, Ctrl+S — идете снова в браузер, все заработало. Что же, на каждую правку 1 буквы — в Git коммитить и пушить, после каждого Ctrl+S?

          Речь идет о РАЗРАБОТКЕ сайта, а не о выкатке его на продакшен. Т.е. о работе с разработческим сервером, где сразу же виден результат работы с исходниками, над которыми вы прямо сейчас работаете.
          • +1
            sparkleshare закоммитит и запушит за вас… а гит сервер скопирует и сделает другие действия по вашему желанию

            а так да, я уже приблизился к пониманию зачем оно нужно
            • 0
              > sparkleshare закоммитит и запушит за вас
              С какой задержкой, вот вопрос. Я обычно выполняю последовательность Ctrl+S — Alt+Tab — Ctrl+R где-то за за 0.3 секунды. Вот за это время изменения и должны на сервер попасть.
              • +1
                не знаю как в windows, в linux по inotify спарклешаре узнает о изменениях сразу же и тут же отправляет, дело не хитрое — в итоге всё упирается в канал
                а уж как гит скопирует и наколдует зависит от того как вы напишите его post-update

                или по inotify bagmify (десятистрочный скрипт на bash) делает тоже самое, не помню =)
                • 0
                  Ну вот если вы попробуете, то увидите, что задержка получится 3-4 секунды, независимо от канала (причем чем больше файлов в проекте и чем длиннее история, тем выше). Git — вещь быстрая, но она быстрая при его использовании в качестве системы контроля версий, а не в качестве передачи каждого неатомарного Ctrl+S на другой сервер. Гвозди микроскопом можно забивать, да неудобно только.
                  • +1
                    сейчас даже не поленился и проверил

                    git push 0,04s user 0,01s system 3% cpu 1,290 total

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

                    единственно излишество по сравнению с RealSync это контроль версий — в этом как плюс, так и минус…
                    • 0
                      А осмысленное сообщение о коммите вы не будете писать? Если нет, то зачем вам гит?
                      • +1
                        нет, не я… но откатиться гитом на нужный день-минуту всяко проще)
                        да и почти 5 мегабайт в архиве это что-то слишком много
                        #!/bin/bash
                        REPO=$1
                        if [ x$REPO = x ];then
                        	echo "Usage: $0 /path/to/dir"
                        	exit 0
                        fi
                        
                        cd  $REPO
                        
                        if [ -d $1 ];then
                        	while inotifywait -r -qq -e create -e close_write -e move -e delete .; do
                        		rsync -avz -e ssh remoteuser@remotehost:/remote/dir $REPO  #можно и не ssh а на nfs/smb
                        	done
                        else
                        	echo "э... чувак, это же не директория"
                        fi

                        или в архиве скрипт + уйма зависимостей для его запуска?
                        • 0
                          Ну, во-первых, скрипт у вас нерабочий. В смысле, в нём есть глюки. Во-вторых, под Виндой и Маком он у вас не заработает.
                          • +2
                            rsync под мак есть ^_^
                            аналог inotify вроде тоже был

                            скрипт рабочий, но писан на коленке меньше чем за минуту — посему далек от идеала
                            • 0
                              rsync под мак есть, inotify нету, там регистрация событий выглядит совсем иначе и утилит командной строки не видел.

                              Если рабочий, то суньте ему в параметры папку, содержащую пробел :) На Маке это частое явление.
                              • 0
                                я же говорю что на коленке, защиты «от дурка» нет, поставить кавычки и всего делов, а вот других проблем в скрипте не мало…
                        • 0
                          В архиве в основном файлы для Windows (ssh.exe, rsync.exe, perl.exe и др.). Для не-винды достаточно файла с именем «realsync» (он в корне архива лежит) и директории bin/ВАША_ОС (для ускорения realtime-отслеживания).
                          • 0
                            а я уж на велосипедизм разругался)
                            Извиняюсь…
                        • 0
                          Да, кстати, насчет вашего скрипта с inotifywait. Вы на каждое изменение запускаете RSYNC всей директории. Это работает более-менее сносно, только когда проект относительно небольшой, и вы на клиенте сидите на Linux или MaxOS. Если же вы работаете в Windows, то там RSYNC очень медленный: только на его запуск уходит 3-4 секунды (почему так — для меня непонятно). Да и NTFS сильно проигрывает по скорости ext4. В итоге такой способ для поимкм Ctrl+S в винде ну совершенно не подходит. Для линукса же или макоси — можно и просто в цикле RSYNC запустить (если проект небольшой, а сеть хорошая, заметьте).
                          • 0
                            согласен

                            но легкость найденного пути решения настораживает…
                            • +3
                              Это у вас не путь решения, это частный случай для маленького проекта, быстрой сети и разработчика, сидящего на линуксе. А бывает еще плохая связь, огромные проекты и разработчики на винде (либо — хорошая связь, огромные проекты и разработчики на винде, либо… ну вы поняли, всего 8 вариантов еще).
                              • 0
                                при плохой связи, уйме разработчиках в разных осях работающих над одним проектом гит и аналоги незаменимы не зависимо от размеров проектов, а RealSync в таких случаях костыль похлеще inotify+rsync

                                а так да, скрипт в пару строк всего-лишь частный случай…
                                • +1
                                  Вы путаете помидоры с пирамидами: RealSync и Git — совершенно из разной оперы. Еще напишите, что по сравнению с iPhone RealSync — страшный костыль.
                • +4
                  А зачем оно в гите то, каждое сохранение кода при разработке? Я вот например давно привык что написал строчку и машинально сохранил. Это ж как засрётся репозиторий, если каждое сохранение пушить то?
                  • 0
                    а вот с этим не поспоришь даже не смотря на то что изменения не так уж много по размеру занимают и можно использовать для сих целей отдельную ветку
                  • 0
                    А система контроля версий, которая приехала в последний Мак, не так ли делает?
                    • 0
                      Вы про Time Machine? Честно говоря не знаю, но что-то мне подсказывает что тут немного разные цели.

                      Time Machine позволяет откатиться до какой-либо даты либо восстановить документ. Предложенное автором решение позволяет просто и быстро синхронизировать локальную папку с папкой на сервере.
              • +1
                Не сочтите за рекламу, один мой друг написал вот такую вещь: livereload.com/

                С ней можно не альттабаться.

                Может вы как-нибудь подружите свои проекты?
                • 0
                  Юрий Насретдинов такую идею высказывал уже. Я считаю ее несколько опасной — в браузере может быть открыта полузаполненная форма, которую не хочется терять, либо вообще — результат последнего POST-запроса. Мне кажется, данная штука скорее мешает отладке, чем помогает, а экономит всего лишь одно нажатие Ctrl+R (или даже F5), так что…
                  • +1
                    Это крутая фича, когда кодишь дизайн. (И когда есть два монитора: на первом код, на втором — гуй).

                    На время отладки интерактивных штук и логики LR можно выключать.

  • 0
    Сам хотел писать подобную утилиту, но так и не дошли руки.

    У нас ситуация точно, как вы описали — у каждого разработчика примаунтеная локально Samba-папка, и Eclipse на ней иногда умирает.
    RealSync может работать через Samba?
    Мне нужно синхронизировать локальные изменения в удалённую папку на сервере, но не по SSH, а по Samba, т.е. локально рабочая папка выглядит как обычная папка (на сетевом диске).

    Нужно будет содержимое локальной папки:
    C:/Users/Вася Пупкин/Мои Документы/Workspace
    синхронизировать в папку:
    N:/путь/к/папке/на/сервере/BasilPupkin/Projects
    где N: — имя диска с примонтированным smb-ресурсом.

    • 0
      Нет, он может работать исключительно по SSH, потому что он на удаленной стороне запускает кусочек своего perl-кода для приема изменений единичных файлов (когда вы на одном файле нажимаете Ctrl+S, он как раз и задействуется). Там все за это завязано. Сложно на сервере поднять SSH-демон?
      • 0
        Такие варианты:
        1. К Linux-серверу есть рутовский пароль, но не охота пускать чужую программу под рутом на боевой сервер, пусть и к девелоперской папке.
        2. К Windows-серверу доступ через Remote Desktop и SMB-папку.

        Дома попробую вашу программу на личном вебхостинге, но на работе желательно синхронизировать только в SMB-папку.
        У Microsoft есть программка для такой синхронизации, но она не может работать автоматически и в фоне — синхронизацию нужно дёргать каждый раз вручную.
        • 0
          1) добавить нерутового пользователя, дать ему доступ к папке.
          2) серверов SSH много для Винды есть.
        • 0
          Подождите, а зачем рутовый пароль? Пускайте под обычным юзером, дав ему доступ к девелоперским папкам предварительно. Вообще, RealSync воспринимает НА СЕРВЕРЕ только ОС *nix (Linux, MacOS, FreeBSD и т.д.), винда на сервере не поддерживается (но поддерживается НА КЛИЕНТЕ).
          • 0
            Важный момент по-моему, что про поддержку, что про кусочек перл-кода.
          • 0
            Вроде, работает.
            Но при старте спрашивает пароль несколько раз.
            И при изменениях (скопировал в локальную папку кучу файлов) спрашивает пароль.
            Курсивом пишу вывод программы:

            [20:09:32] Detected changes in more than 10 objects. Running rsync: it's faster.
            Password:


            После ввода пароля задумывается надолго:

            sending incremental file list

            И неспеша копирует файлики.
            После очередного ввода пароля на выдачу следующих строк:

            ./
            .htaccess

            sent 2236587 bytes received 4416 bytes 24491.84 bytes/sec
            total size is 802144234 speedup is 357.94


            … ушло полминуты.

            Скопировал в наблюдаемую папку папку с вашей программой, программа выдала в консоль такое:

            [20:15:32] Detected 3 change(s), transmitting…
            [20:15:33] DIR: ./lalatest/dklab_realsync — done
            [20:15:33] FIL: ./lalatest/dklab_realsync/README.txt (8338 bytes) — done
            [20:15:33] FIL: ./lalatest/dklab_realsync/realsync (40520 bytes) — done
            [20:15:33] Detected changes in more than 10 objects. Running rsync: it's faster.
            Password:


            И ждёт ввода пароля.

            Можно как-нибудь запомнить пароль, чтобы не вводить каждый раз?
            Хотя бы в конфиге, открытым текстом.
          • 0
            В общем, перед каждой пачкой синхронизируемых через rsync файлов происходит запрос пароля.

            Программу скачал с вашего сайта час назад.
            Сейчас скачал с гитхаба последнюю версию — тоже запрашивает пароль каждый раз.
          • 0
            Повысил $MIN_CHANGES_FOR_RSYNC с 10 до 1000 — теперь пароль спрашивает только два раза при старте программы.
            Синхронизирует быстро.
            Всё работает.
            Спасибо.
          • 0
            Всё же иногда запрашивает пароль.
            Например, после удаления подпапки.
          • 0
            Ещё проблема: через какое-то время perl-процесс занимает 100% CPU на сервере.
            Закрытие локального клиента проблему не решает, приходится убивать процесс на сервере.
  • 0
    Уточню пара вопросов по реализации. Perl не очень знаю, так бы сам посмотрел.

    1) Правильно понимаю что в зависимости от ситуации используется rsync или свой протокол?
    2) rsync натравливается на все дерево каталогов или только на ту часть, на которую «доложил» демон-нотификатор?
    3) На MacOS FSEvents умеет сообщать только в каком каталоге произошло изменение, но не в каком файле. Как с этим разбираетесь?
    4) На Linux по-моему Inotify не отличает переименование от удаления и создания. Используете cookie или что-то проще?
    5) Храните ли снепшот дерева каталогов? Если да, то каким алгоритмом сравниваете снепшот с текущим состоянием?
    • +1
      1. Да. RSYNC используется а) при запуске утилиты, б) когда вы изменили за раз больше N файлов (в данном случае N=10). Во всех остальных случаях используется свой протокол.
      2. RSYNC натравливается на все дерево.
      3. Там где-то строчек 100 про это как раз в коде. В целом — RealSync хранит в памяти дерево каталогов и при сигнале от FSEvents обновляет ту часть этого дерева, в чьих папках произошли изменения. Дальше делает diff и, если в diff меньше 10 файлов, использует свой протокол, а если больше, то RSYNC. Все это происходит незаметно.
      4. Да нет, точно такой же способ, как в (3). Просто сканируются измененные папки (но не рекурсивно), этого достаточно.
      5. Да, он хранится в памяти, пока утилита работает. Снимается с нуля непосредственно перед каждым запуском RSYNC (это занимает 2-3 секунды на больших проектах), а дальше поддерживается в актуальном состоянии инкрементально.
  • +1
    Для Notepad++ есть плагин Auto Save, который умеет сохранять все измененные файлы (в том числе на FTP) при потере фокуса приложением. В итоге когда я нажимаю Alt+Tab для того чтобы переключиться на браузер, мои измененные файлы (CSS, PHP) уже закачаны на сервер и остается только нажать F5. Для комфортной работы конечно нужен быстрый интернет и шустрый сервер с короткой трассировкой до него.

    Проблему с поиском я решаю очень грубым методом, но мне этого пока хватает. Раз в неделю-две делаю бэкап всех файлов проекта, по которому можно искать. Повторюсь — для сложных проектов возможно не пойдет, но в моей ситуации выручает, т.к. ищу не часто.
    • 0
      Штука в том, что недостаточно просто передать 1 файл на Ctrl+S. Нужно заботиться о том, чтобы ВСЕ ДЕРЕВО было идентичным, в любой момент времени. Даже в случае, если админ случайно забредет на сервер напрямую и что-то подправит в ваших файлах, или что-то с ними произойдет (например, из бэкапа восстановят вместе с другими файлами и т.д.). А это задача не очень тривиальная (если 1400 строк Perl-кода и внушительное время на отладку можно назвать нетривиальным, конечно). Нужно как минимум ловить дисконнекты и уметь запускать RSYNC в нужный момент, а также много чего еще.
      • 0
        Дмитрий, я не пытаюсь приуменьшить заслуги RealSync. Это действительно крутая штука, и с этим никто не спорит.

        В моем случае я знаю что на сервер захожу только сам и никаких админов там нет. Я говорю только про свой случай, что мне удобнее нотпад с автосейвом. И обратите внимание, в моем предыдущем комменте я говорю о сохранении всех измененных файлов по Ctrl+S или при потере фокуса.
  • 0
    Давненько ищу подобную утилиту, но для репликации большой папки с картинками (сейчас она порядка гигабайта) с серверной в локальную папку. Естественно, синхронизировать нужно только изменения.

    rsync не осилил, да и настраивать на каждом компе разработчика сложновато. Использую GoodSync, но работает оочень медленно и такое ощущение, что делает много лишних операций.

    Ваша утилита для этого подойдет? Или мб вы другую подскажите, раз разбирались в этом вопросе и вероятно искали существующие решения в этой области.
    • 0
      Если вы ее запустите на сервере и она сможет коннектиться к каждому разработчику на его комп (а у разработчиков Линукс или Мак), то подойдет. Но вообще, она для обратного процесса — синхронизации исходников ОТ разработчика НА сервер.

      Вообще, вы точно уверены, что у каждого разработчика должен быть локальный гигабайт картинок, еще и обновляемый в реальном времени? Мне кажется это странным. Можете описать, почему такое необходимо?
      • 0
        Нужен даже не гигабайт, а скорее нужны картинки, загруженные за последние несколько дней. Это, разумеется, можно делать и вручную, но значительно удобнее это автоматизировать, чтобы сэкономить время.

        Полагаю, что задача распространенная. Нужно тестировать функционал, связанный с этими картинками — обработка, вывод и так далее. При этом каждый день появляются новые картинки на продакшн сервере, где запущен сайт.
        • +1
          Ну у вас же разработчики работают не с продакшен-сервером напрямую, верно? Или вы картинки с продакшена берете, кладете разработчикам на локальные машины, а разработчики работают на локальном же веб-сервере? В этом случае я бы все же посоветовал RSYNC им настроить — это несложно, всего лишь bat-файл сделать и рядом закрытый ключ положить, сказать им, чтобы этот bat-файл запускали раз в сутки. Это явно выходит за сферу применимости RealSync.

          А еще лучше — предложил бы вам написать утилиту, которая кладет разработчикам не сами картинки с продакшена, а сгенериированные заглушки с теми же именами. Тогда вообще ничего можно было бы не синхронизировать — запускаете утилиту, и все дела.
          • 0
            Спасибо большое за второй вариант. Самому как-то в голову не приходило, а ведь вариант очень интересный, все упрощает и ускоряет.
  • 0
    Я как-то глухо не догоняю
    У меня есть аккаунт на bitbucket, я использую git, и вроде никаких тулов не нужно.

    Что эта штука дает по сравнению с обычным контролем версий?
    • +1
      Возможность не захламлять систему контроля версий однобуквенными коммитами на каждый чих и автоматизацией.
    • +1
      Э-эээ… Эта штука не для контроля версий, а для замены Samba, когда Samba тормозит. Если жаль времени на статью, то можно в комментариях прочитать подробности.
  • 0
    Спасибо за отличный инструмент, раньше пользовался для этого связкой из четырёх утилит, теперь будет только одна! И да, ваша продуктивность поражает.
  • +1
    Дим, мне кажется было бы честным сказать, что двухсторонней репликации нет потому, что под windows не работает должным образом select() в Perl :).
  • 0
    Вот бы еще в 2 стороны :)
    Но всё равно за утилиту спасибо!
    • 0
      Даже с точки зрения интерфейса 2 стороны потребует человеческого вмешательства в случае, если вы одновременно изменили один и тот же файл и там, и там. Это довольно нетривиальная вещь. Как вы будете разрешать конфликты? Разве что открывать что-то типа WinDiff и давать на панелях сравнивать.

      Задумайтесь — может быть, вам и не нужна двусторонняя синхронизация (в подавляющем большинстве случаев это так). Просто с использованием RealSync надо перестать воспринимать удаленную папку как нечто самостоятельное. Она становится лишь read-only «зеркалом» для вашей локальной папки, и если что-то хочется менять, то надо это делать в локальной папке, забыв про удаленную вообще.
      • 0
        Приведу свою модель работы:
        Десктоп с линукс на борту и внутренний офисный линукс сервер с личной папкой каждого сотрудника компании.
        В работе использую PhpStorm напрямую с папкой сервера (соединение с сервером идет посредством sshfs, так же параллельно открыта серверная консоль, в которой произвожу коммиты и «svn up/pull»ы).
        Так вот, после апдейтов серверных «svn up/pull» — третий PhpStorm не сразу сечёт изменения, и после собственных правок кода вываливает окно мержа, которое и вызывает кучу неудобств.
        Скорость sshfs и перманентная загруженность сервера оставляет желать лучшего.
        Соединение с удаленным сервером посредство средств PhpStorm не устраивает, по причине необходимости лишних действий с загрузкой/отгрузкой проектных данных.
        Посему, на данный момент вижу авто синхронизацию 2-х сторон лучшим и удобнейшим из методов.
        • +1
          Ну ваша модель отлично ложится на RealSync. Вам только надо SVN использовать на своей же локальной машине, а не на дев-сервере (заодно и GUI какой-нибудь подтянется — в том же phpStorm-е есть средства для работы с SVN). А про серверную консоль можно забыть, она в данном случае не нужна. Файлы правятся только локально.
          • 0
            Спасибо за совет!
        • 0
          В PhpStorm есть работа с удаленным хостом + автоматическая выгрузка изменений (не очень понял про лишние действия с выгрузкой данных, видимо, не включен Automatic Upload). В данной схеме, RealSync выглядит 5 колесом.
          • 0
            Предположим, я ушел в оффлайн на несколько дней. Поправил несколько файлов (не обязательно в phpStorm-е, может быть, и в других редакторах). За это время кто-то что-то испортил в моей папке на сервере тоже. После этого я возвращаюсь в онлайн. Каковы будут действия phpStorm-а и сколько времени они займут, напишите, пожалуйста (желательно поподробнее).
            • 0
              1. странно работать с кодом без возможности его проверить
              2. внешние правки кода будут видны по измененным файлам, но выгрузка автоматом не запустится. скорость процесса выгрузки зависит от канала, сервера и тп, в моем случае — быстро.
  • +1
    Я уже писал у вас на форуме ещё при первом анонсе утилиты, ответа не получил. Напишу сюда. Win7, штатный доступ на сервер через putty, запущен pageant с ключом, через который должна происходить авторизация.

    Запускаю realsync — и при _каждой_ операции он запрашивает пароль. Как объяснить ему, что надо использовать pageant или хотя бы научить запоминать пароль?
    • 0
      Уточните вашу конфигурацию. В общем случае пароль запрашивается 1 раз при самом-самом первом запуске утилиты, после чего генерируется открытый и закрытый ключ. Закрытый ключ используется RealSync-ом в дальнейшем, а открытый — кладется им на сервер. Я не очень понимаю, при чем тут pageant и вообще PuTTY (RealSync использует cygwin-овский ssh.exe).
      • 0
        Что именно из конфигурации нужно уточнить? Спрашивайте — отвечу.

        Вот так выглядит сеанс создания синхронизируемого каталога: pastie.org/private/4uhrqlyxfmw9skkxt23ew После этого realsync бесконечно спрашивает password и ничего не происходит. Куда смотреть, куды бечь?

        И, если у меня настроена SSH-авторизация по ключу, а не по паролю — как быть в таком случае?
        • 0
          Что-то странное случается: в фразе «checking if we have access without a password to this host» у вас не должен был запроситься пароль — вместо этого он должен был сказать, что доступа без пароля нет (т.к. запускается ssh -q -o PasswordAuthentication=no), и сгенерировать пару ключей. Я попробую воспроизвести это сейчас.

          Если у вас в системе УЖЕ настроена SSH-авторизация по ключу, то RealSync ее автоматом подхватит и вообще не будет запрашивать пароль даже в первый раз. Только вот формат ключей (и их расположение) для PuTTY и Cygwin-овского SSH — разные. В случае ssh.exe ключ берется из %HOME%\.ssh\identity.

          Попробуйте положить identity туда (в моем случае это C:\Users\d\.ssh\identity) и запустить
          ssh.exe david@****.ru
          в консоли Windows. Вас должно пустить по SSH на ****.ru без пароля. Если не пустило — надо смотреть, может быть, настройки на сервере какие-то не такие (или на клиенте) или еще что. Для диагностики может помочь ssh.exe -v, например.
          • 0
            Давид, попробуйте, пожалуйста, в скрипте рядом с

            -o PasswordAuthentication=no

            добавить еще

            -o BatchMode=yes

            И посмотреть, перестанет ли он у вас спрашивать пароль сразу после фразы «checking if we have access without a password to this host». У меня хватает и PasswordAuthentication=no, но, возможно, на вашей системе этого недостаточно?
            • 0
              Да, вот с этим ключом всё заработало как надо, пошла репликация.

              Ок, файлы перекачались на удалённый хост, теперь каждые 3 секунды реалсинк показывает сообщение, что он что-то качает (файлы я при этом не меняю):

              [18:39:00] Watching for changes in 2 folder(s)…
              [18:39:00] SSH client died, restarting.
              [18:39:00] Initiating a background connection with /home/david/tmp/ttt…
              [18:39:00] Fast initial rsync synchronization…
              defined: Событие не найдено.
              sending incremental file list

              sent 604 bytes received 13 bytes 411.33 bytes/sec
              total size is 9606830 speedup is 15570.23

              [18:39:01] Watching for changes in 2 folder(s)…
              [18:39:01] SSH client died, restarting.
              [18:39:01] Initiating a background connection with /home/david/tmp/ttt…
              [18:39:01] Fast initial rsync synchronization…
              defined: Событие не найдено.
              sending incremental file list

              sent 604 bytes received 13 bytes 411.33 bytes/sec
              total size is 9606830 speedup is 15570.23

              и так далее…
              • 0
                «SSH client died, restarting.» означает, что умерло постоянное SSH-соединение с сервером, которое RealSync все время держит открытым поддерживает для быстрой передачи единичных файлов. Последите, пожалуйста, в списке процессов, что с ним происходит. Я лично не понимаю, почему он умирает без единого сообщения в консоль… Какая ОС, кстати? И — не запущено ли еще где-то у вас cygwin-процессов (вдруг конфликт версий)?
                • 0
                  Cygwin у меня точно не запущен, его просто нет. ОС на сервере довольно древняя — freebsd 6.4. В логах на сервере, вроде, ничего не происходит…

                  Попробовал на другой системе, свежей.

                  [19:18:16] Watching for changes in 1 folder(s)…
                  [19:18:16] SSH client died, restarting.
                  [19:18:16] Initiating a background connection with /usr/home/david/ttt…
                  [19:18:16] Fast initial rsync synchronization…
                  defined: Event not found.
                  sending incremental file list

                  Что такое defined: Event not found? Это явно rsync говорит…
                  • 0
                    А, стоп. У меня там шелл tcsh. И, похоже, event not found — это его… Ладно, думаю тут уже мне самому надо поэкспериментировать.
                    • 0
                      Давид, это реально проблема несовместимости с tcsh на сервере. Сейчас переключил у себя — выдает точно такие же сообщения. Я попробую сейчас сделать совместимым и с tcsh, конечно, но все же bash — наше все…
                    • +1
                      В итоге победить удалось. Дело в, мягко говоря, странной реакции TCSH на "!", даже заквоченный в АПОСТРОФЫ. Собственно, попробуйте в TCSH запустить такую команду:
                      echo 'a!b'
                      Получите «b: Событие не найдено.» — жуть просто, кто это придумал…

                      Сделал обходной маневр, теперь работает и в TCSH. Обновитесь. Вот коммит для интересующихся: github.com/DmitryKoterov/dklab_realsync/commit/883bf94e53c14076a7da7cf155daa5c17bff10c7
                      • 0
                        Большое спасибо! На всякий случай, экранирование echo 'a\!b' также работает (но я не проверял, насколько оно совместимо с прочими шеллами).
                        • 0
                          Я проверял — несовместимо, к сожалению (с bash-ем, по крайней мере). Поэтому то решение и реализовано, которое реализовано.
                          • 0
                            Если я Вас ещё не очень задолбал, то сообщаю, что всё запускается, рсинкится, но обновления файлов (при работающей утилите) ни фига не отслеживаются:)

                            Если утилиту закрыть, а потом снова запустить, всё что изменилось нормально с rsync-ится. Но нотифай такое впечатление что не работает (хотя сам процесс живой). В консоли при изменении файлов нет никаких сообщений. Win7, 64, NTFS… ну не знаю даже, куда ещё посмотреть.
                            • 0
                              Ни в коем случае не задолбали. Чем больше фидбека — тем лучше. Попробуйте открыть директорию, в которой производите изменения, в cmd. Затем там запустить:

                              путь\к\realsync\bin\win32\notify.exe

                              Оно подвиснет и начнет ждать. Далее в Проводнике попробуйте поменять какой-нибудь файл в директории. Notify.exe должен начать печатать имена измененных файлов. Если это происходит, то проблема где-то в буферизации на стороне Perl; если нет, то может быть какая-то проблема с notify.exe на вашем компе.
                              • 0
                                Отчитываюсь: notify.exe сам по себе работает, изменения в файлах ловит.

                                Я поставил $DEBUG_PATCH_TREE = 1, получается вот какой вывод (меняю файл TODO.txt):

                                Received: M TODO.txt
                                Notify: TODO.txt
                                Received: M TODO.txt
                                Notify: TODO.txt
                                Received: M TODO.txt
                                Notify: TODO.txt
                                Candidate: ./TODO.txt

                                И всё. Из того что я пока нашёл: на выходе из get_changes — пустой массив, если раскомментировать отладочную печать (стр. 611):

                                foreach (@cur_tree) { print $_->{name}. "\n"; } print "\n";

                                то выводится просто точка (".").
                                • 0
                                  А, блин! Дмитрий, простите, тут я самдурак. Зачем-то вписал в исключения паттерн '.*', и он рубил, естественно, всё что в текущем каталоге:)

                                  Сейчас вроде всё работает как надо — спасибо Вам за помощь и за терпение:)
                                  • +1
                                    М-ммм… Давид, вообще-то, вы баг нашли. :-) Маска ".*" не должна совпадать со всеми файлами. Она должна совпадать только с файлами, начинающимися на "." (и с директориями). А совпадала она, потому что во внутреннем представлении RealSync хранит все пути в виде "./dir/file" — всегда с "." в начале, вот с этой единственной точкой и совпадала маска ".*. Баг исправлен, можно обновиться — коммит github.com/DmitryKoterov/dklab_realsync/commit/5e3e8bf6548a0b0912e9c1e914661627df536284
                                    • 0
                                      Тогда просто для ясности — маска накладывается строго на имя файла или на путь отн. текущего каталога? То есть, могу ли я написать маску "/abc/*.txt"? Вроде бы кроме отбрасывания начальной точки патч ничего больше не меняет.

                                      И как работают маски в режиме rsync? Потому что у меня с маской ".*" начальный rsync всё равно синхронизировал изменённые файлы.
                                      • 0
                                        Маски передаются один-в-один в rsync, в том виде, в котором они прописаны в exclude. Так что это именно маски rsync. Сам же RealSync пытается также трактовать маски как можно более ближе к тому, как это делает rsync (полной точности вряд ли удалось добиться, но для большинства случаев подходит).

                                        Основная идея в том, что маска преобразуется в нормальное регулярное выражение (см. sub mask_to_re — правда, она достаточно сложная), после чего она матчится с относительным путем, из которого предварительно отрезана ведущая точка. В случае, если маска содержит хотя бы один "/" или последовательность "**", она воспринимается как АБСОЛЮТНАЯ и матчится с ПОЛНЫМ относительным путем (от начала и до конца). Если же "/" в ней нет, то с маской матчится хотя бы один кусочек относительного пути.

                                        В вашем примере /abc/*.txt (равно как и маска abc/*.txt) будет матчиться только с txt-файлами в директории 1-го уровня abc, и все.

                                        С маской ".*" начальный rsync у меня сейчас корректно передает все файлы, кроме начинающихся с точки (что есть правильно). У вас разве не так? Можете прислать лог?
                                        • 0
                                          ОК, логика понятна. Нет, у меня сейчас всё нормально работает, ещё раз спасибо за помощь. Полезная утилитка!
          • 0
            Попробую. Пока что дебаг-выдача вот какая: pastie.org/private/hwqqrrkzpqism3gxugs9g
            • 0
              А эта же командная строка с добавленным дополнительно -o BatchMode=yes?
  • +1
    Интересно, а как вы организуете командную разработку с вашим «репликатором»? Для одного человека — более чем удобно, но где вы такое видели? Для реального мира есть гит + локал энвайронмент. Уже столько всяких штук придумали для облегчения запуска сторонних компонентов, что никаких проблем поднять на ноутбуке продакшен энвайронмент нет. Мощности лэптопов достаточно, чтобы гонять solr, memcached, postgres, rabbitmq и сам сервер приложения, да еще и на эклипс прожорливый останется.

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

    Насчет ctrl + s -> alt + tab -> ctrl + r: Вы верстаете? Пишете js? Зачем для верстки или js весь стек поднимать? Если нет, то «обычно» большая часть времени проходит за тестами и браузер вам не особо нужен.

    Мне кажется, лучше выбрать другой воркфлоу проекта и не создавать велосипеды, хотя если очень хочется, то :)
    • 0
      Как организовывается командная разработка, можно прочитать в статье выше. Вкратце — у каждого разработчика своя директория на сервере (у каждого она своя, они независимы), и на эти директории мапятся различные домены дев-сервера (или различные порты). Например, example.com.ЛОГИН_РАЗРАБОТЧИКА.lcl или example.com: ПОРТ_РАЗРАБОТЧИКА. Синхронизация же исходников (командная работа) происходит через человеческие средства — например, через Git и SSH (это не имеет отношения к RealSync).

      Вы сейчас, насколько я понимаете, говорите о локальной разработке, когда веб-сервер (и СУБД?) стоит у каждого разработчика свой, на своем ноутбуке. Я ничего не имею против такой схемы и сам ей пользуюсь для ряда проектов (см. статью выше опять же), но только есть случаи, когда она может быть не очень удобной.
      • 0
        Такой воркфлоу попахивает ужасом.

        Не могли бы Вы привести пример, когда локал девелопмент является неудобным?
        • 0
          1. Когда существенно используются возможности той или иной ОС на сервере (например, Линукс), а разработчики работают на винде.
          2. Когда СУБД очень большая или просто часто и нетривиально меняется, так что ее приходится держать в единственном экземпляре на дев-сервере, а разработчики со своих локальных машин коннектятся к ней по сети из скриптов сайта (этот коннект — медленный, если вы работаете удаленно, а не сидите в офисе).
          3. Когда разработчиков много и они не все разбираются в особенностях конфигурации, а сайт очень сложный.
          4. Когда даже в дев-зоне много серверов.

          Про ужас — вы не ошибаетесь, он точно так же имеет право на жизнь, как и локальная разработка. Просто для разных проектов — разные способы, надо выбирать наиболее удобный.
          • +1
            Не удержался и написал ответ, уж очень аргументы мне не нравятся

            1. Это сильный аргумент! Правда, если у вас 10 разработчиков, можно из всех пересадить на линукс.
            2. Для разработки можно жить из без бд, особенное если пользоваться тестами. Кроме того, в девелопменте не всегда нужна актуальная и полная база. Достаточно структуры и нескольких тестовых записей.
            3. Даже если каждый разработчки изолированно разбирается в своем куске кода (тогда зачем ему вся БД), это совсем не уменьшает удобства гита и локальной разработки. Если разработчики не умеют пользоваться гитом — то или учить или гнать.
            4. Разве кол-во серверов имеет значение? Мне кажется, гораздо важнее кол-во сервисов. И установить все на средний ноутбук не составляет проблем.
            • 0
              Я согласен, что лучше быть богатым и здоровым, чем бедным и больным. Но реальность богаче, увы.
        • 0
          Плюсов много, на самом деле.

          1) Когда требуется достаточно много различных компонент — их администрирует штатный админ, от разработчика разбираться в нюансах софта вне его прямых обязанностей не требуется.
          2) Все разработчики используют одно и то же окружение. Особенно это важно, когда хороший кусок этого окружения — самосбор, и просто так из репозитория не ставится.
          3) Легко можно зайти друг к другу в каталог — чтобы помочь или скопировать себе какой-то кусок кода
          4) Легко можно зайти на версию сайта от другого разработчика, при этом нет необходимости быть с ним рядом или как-то извращаться с пробросами портов, VPN и тому подобным.
          5) Какие-то инфраструктурные глюки сразу заметны — если есть проблемы с версионником, или с соединением с сервером — можно выяснить у коллег, есть ли у них такое, и если есть — высвистывать поддержку.
          6) Если человек по каким-то причинам пропал его код никуда не делся, даже если не закоммичен
          7) Если есть необходимость с девелоперских сайтов взаимодействовать с какими-то внешними сервисами, доступ на которые ограничен по IP

          В общем, для большого проекта — хороший вариант
      • 0
        А не поделитесь своими наработками по автоматической конфигурации хостов для разработчиков?
        Генерите конфиги для apahe/nginx/etc по шаблонам?

        У меня постоянная проблема с тем что окружение девелоперских машин не совпадает с тестовым и продакшн-окружением.
        • 0
          Nginx по шаблону, да. Но, на самом деле, в качестве этого шаблона выступает сам конфиг, в нем только подстроки "/web/" и ".web." заменяются на строки "/ЛОГИН/" и ".ЛОГИН." для каждого разработчика (сканируется /srv/www/ и все папки, которые нашлись там, становятся «разработчиками»). Это дело размножается и включается в конфиге nginx через include. Всего делов-то. На продакшене в /srv/www только одна папка — web, поэтому и разработчик там как бы один-единственный (с именем «web»), т.е. ничего не размножается и не сканируется как будто бы.

          А имена доменов строятся по схеме ПолноеИмяНаПродакшене.ЛОГИН.КЛАСТЕР.lcl. Здесь ЛОГИН — логин разработчика (или web; типа web — это такой «виртуальный разработчик», у которого в домашней директории весь сайт, но который только пулится, ничего не коммитя). КЛАСТЕР — это dev (дев-сервер), test (сервер репитиции релиза), load (нагрузочные тесты) и prod (продакшен). А ПолноеИмяНаПродакшене — это типа example.com или my-site.ru или что угодно.
          • 0
            Ну и, естественно, конфиг nginx хранится в git, поэтому он одинаковый и не дев-сервере, и на продакшене. Этого не так уж и сложно добиться, чтобы не было завязок за всякие там ip-адреса, порты и т.д.
            • 0
              а конфиги nginx в том-же репозитории? Или просто отдельный репозиторий для конфигов и при добавлении юзера просто перегенерите? Я задумался тут — может такое к gitolite прикрутить ;-)
              • 0
                Конфиги nginx-а в том же репозитории, зачем еще один. Но сгенерированные конфиги — вне, конечно же, они же на лету генерируются и только на дев-машине (на продакшене ничего генерировать не нужно). На продакшене можно /etc/nginx симлинкой сослаться на правильную папку с конфигами nginx внутри репозитория.
                • 0
                  Попробовал на одном из проектов использовать realsync

                  оказалось можно обойтись несколькими строками в nginx (выделяя логин разработчика прямо в директиве server_name) и даже апач легко настраивается аналогично используя VirtualDocumentRoot и wildcard в ServerAlias
    • 0
      Дев-окружение у меня крутится в виртуалке, чтобы максимально точно соответствовать боевому. Не то чтобы с различиями между Debian и Ubuntu реально сталкивался, но береженого… В общем почти ноутбук и сервер на кухне.

      Так вот, неудобны для этого VCS по двум причинам:
      1. Для проверки изменения нужно его закоммитить, запушить, переключиться на консоль дев-сервера, сделать пулл, переключиться в браузер, проверить, обнаружить опечатку, переключиться в исходники, исправить, повторить пока не заработает.
      2. В репозиторий проникают коммиты «заведомо» не работающие или с ошибками, за ними следуют один или несколько с исправлениями в один-два символа.

      Обеих проблем можно было бы избежать во многом, обеспечивая 100% покрытия всего кода (включая html и т. п.), но зачастую это превращается в тесты ради тестов, а главное 100% гарантии отсутствия опечаток (бог с ними с логическими ошибками) они не дают.
      • 0
        тестировать вьюхи — это действительно жестко.

        Кстати, поднимать виртуальное работчее окружение можно с помощью chef, но это уже задача админов делать рецепты. Зато если сделать — не будет проблем поднять виртуалку еще одному разработчику. Еще более простое решение — сделать один настроенный образ на всех разработчиков.
        • 0
          Начиная новый проект с нуля я чувствую либо необходимость в компромиссе какую часть кода не тестировать (даже не вьюхи, а шаблоны вьюх), либо необходимость тестировать всё, без оглядки на здравый смысл (по началу, пока вёрстка не готова, в тестах проверять наличие, например, тега html корневым, тега head прямым и первым его «ребёнком», а тега title прямым «ребёнком» тега head, а потом сравнивать с вёрсткой от верстальщика с её адаптацией под тесты — это если верстаю не я). Если следовать букве TDD, то последнее это логично («ни строчки кода без теста, который без неё не выполняется»), но субъективно избыточно — мое представление о вёрстке тесты на основе селекторов могут проверить, но что она будет выглядеть как я представляю — нет)
          • 0
            Я совсем не понимаю зачем тестировать вьюхи. Особенно верстку и шаблоны. Зачем?
            Юнит и интеграционных тестов вполне достаточно.
            • 0
              Как я понял основной принцип TDD — у каждой строчки (утрируя, на самом деле — у каждой лексемы) кода должно быть обоснование в виде порушенного (в свое время) теста. Минимум — любое значимое изменение кода (включая изменение, например, тега a на тег b в коде шаблона) должно влечь за собой нарушение тестов. Иначе мои тесты не охватывают весь входной диапазон параметров (включая текст шаблонов), либо неправильно охватывают диапазон выходных параметров (например, видят тег head с нужным содержанием, но не обращают внимания на то, что он где-то внутри div'а третьего уровня вложенности, а не первый наследник тега html).

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

              Полноценные приемочные тесты должны анализировать и (прежде всего?) семантику, а не только синтаксис. В случае XML вывод скрипта должен, как минимум, соответствовать DTD или Scheme — они могут (но не обязаны) гарантировать семантическую целостность. В случае других языков вывода (html, css, js и т. п.) гарантировать хоть как-то, что конечный вывод (читай — содержимое окна) пользователю соответствует ожидаемому формально очень сложно без анализа полного текста документа (про разнообразие интерпретации браузерами, что html, что css, что js, я, пожалуй, промочу).
        • 0
          Про chef забыл написать — пытался освоить его или puppet, но решил что для моих задач они избыточны. Прежде всего потому что они представляют (в отличии от капистрано), что веб-сервера это их клиенты. На моих задачах обычно наоборот: сервер — это сервер, он должен обслуживать запросы клиентов (пускай и с рутовыми правами) — такой системы, чтобы задавала извне требования по соответствию состоянию и с DSL-синтаксисом я не нашёл. Chef- и Puppet- клиенты (которые в «нормальной жизни» серверы) пытаются соответствовать тому описанию, которое ему сообщает сервер по их запросу меня не устраивают, а капистрано для таких задач не заточен — нарисовать можно, но от обычных bash-скриптов отличаться не будет по сути.
          • 0
            не совсем понял, чем вам не подходит chef.
            Я говорил про шеф в контексте развертки окружения разработчика.Не обязательно держать на chef-сервере всю конфигурацию и цеплять клиентов. Достаточного одного репозитория с шеф-соло, с помощью которого разворачиваются новые машины.
            • 0
              Тем, что нет бесплатных приватных серверов chef, аналогичных по сути бесплатным приватным git/hg репозиториям на bitbucket.org.

              Тем, что нужен хоть один хост с развернутым chef-сервером, который может принимать внешние соединения от chef-клиентов.

              Тем, что нет возможности сделать инверсию управления по отношению к серверам.

              P.S. Может я не слишком вникал в возможности chef, но читая гайды, топики на хабре, и нагугленные блоги (последовательность рандомная, начинал с хабра), я понял, что без хоста, способного слушать порты в сети, к которым обращаются сервера с разворачивающейся средой, не обойтись. Управляющий центр — пассивный хост, который только отвечает на вопросы типа «я активный хост, каким я должен быть», но не активный хост, который говорит пассивным «я бог — слушай меня: твое окружение должно соответствовать такому-то».

              P.P.S. Может мои соображения меркантильны, но, по-моему, нет смысла держать два vds, чтобы обеспечить развёртывание второго при смене второго на основание конфигов первого. Буду очень благодарен, если кто мне подскажет сценарий использования chef на локальном хосте, не имеющем возможности слушать порты извне (провайдерский NAT) для разворачивания инстансов моих приложений на (v)ds под управлением debian/ubuntu. Или очень дешевый (~1$ в месяц) способ содержать «вечно» полноценный chef-сервер для развертывания среды исполнения приложений под «голым» Debian/Ubuntu.
              • 0
                chef-сервер и его можно установить себе приватно.
                Если не охота возиться с сервером, есть chef-solo. И потом его сколько угодно раз копировать на другие машины. Из хостинга надо только где-то хранить файлы chef-solo. Хоть на гитхабе, хоть на народе в зип архиве
  • 0
    Когда на работе перешёл на таскаемый туда-сюда ноут, задумался о том как бы было проще синхронизировать и что бы код был всегда локально. Первое на что наткнулся — realsync. Юзаю около двух месяцев. Пока вообще никаких нареканий.

    З.Ы. Когда прописал в .gitignore .realsync подошёл один из сотрудников и спросил — неужели я правда пользуюсь realsync. Оказалось что он один из тех что что-то писал для этой тулзы.
    • 0
      Вспомнил что не хватает, только даже мыслей нет как реализовать. Проект мультиязыный, но разработка ведётся на одном языке. Иногда надо потестить как там в переводах выглядит и тогда на девел сервере запускается скрипт перевода, который создаёт папку (на девеле сервере) с шаблонами. Всё отлично потестили. Но как только переключаешь ветку на локальной машине — все переведённые шаблоны удаляются. Есть какой-нить эксклюд для серверной стороны?
      • 0
        Думаю, не только когда ветку переключаете, но еще и когда связь на время рвется так происходит, ибо запускается полный RSYNC. На сервере должны работать те же самые эксклюды, см. конфиг .realsync. Должно помочь.

        А вообще — лучше запускайте этот скрипт на локальной машине…
        • 0
          там слишком много энвайромента для перевода и вообще функционирования скриптоа… Да и база переводов удалённая… Ну то есть скрипт запускать на локальной — не вариант. Попробую эксклюды на сервере зафигачить.
  • 0
    Сори если не заметил, но чем это отличается от подобных фич в ideшках?
    • 0
      Из статьи: «Почти все IDE поддерживают передачу измененного файла (по FTP или SSH) на удаленный сервер при нажатии Ctrl+S. Но только здесь две проблемы. Во-первых, вы не сможете изменять файлы «мимо» IDE (например, сделать git pull из командной строки на локальной машине). Во-вторых, если вы на несколько дней исчезнете из реальности интернета, а потом вернетесь с измененными файлами, IDE уже не сможет определить, какие файлы изменились (особенно если они еще случайно и на сервере поменялись почему-то независимо от вас), и в лучшем случае начнет полное копирование, что займет полчаса.»
  • 0
    На форуме уже спрашивал, не получил ответа.
    В чем преимущества перед "Unison file synchronizer"? В отличии от realsync есть двухсторонняя кроссплатформенная автоматическая синхронизация.
    • 0
      В устойчивости к разрывам связи, скорости работы и общей неприхотливости. В целом все это можно ощутить, попробовав поработать и с тем, и с другим месяцок. Дьявол в деталях.
  • 0
    Что выглядит не очень хорошо:

    1) Запрашиваются пароли для ssh. Адекватные разработчики паролей для SSH давно не имеют, работают иключительно с помощью ключей. Putty и pageant, как я вижу по исходникам, не поддерживаются? А ели и будут поддерживаться, начнутся проблемы с rsync.
    2) как отслеживаются изменения в директориях? Используется ли под windows интерфейс операционной системы для этого?

    WinSCP всех этих недостатков не имеет (имеет другие) — вот оно реальная альтернатива. Если бы только не его недостатки, то был бы идепльный синхронизатор.
    • 0
      1. Положите ваш приватный ключ в C:\Users\ВашЛогин\.ssh\identity — он подхватится RealSync-ом при первом запуске, и пароль не будет спрашиваться вообще ни разу. Просто ключ для PuTTY и ключ для SSH — разные (зачем-то PuTTY пошел по такому непонятному пути, хотя в нем есть утилита конвертации).
      2. Да. Для каждой ОС используется ее нативный механизм.

      WinSCP:
      — неустойчив к разрывам связи (вернее, устойчив через пень-колоду)
      — очень долго проводит начальную синхронизацию (в десятки раз медленнее, чем rsync в RealSync-е)
      — не так легко конфигурируется, как RealSync

      Но да, это одна из альтернатив для сильных духом мужчин.
      • 0
        Ну как это пароль не будет спрашиваться ни разу? А пароль для приватного ключа откуда будет браться? Или генерировать приватные ключи без пароля? Страшновато. putty пошёл по своему понятной причине — формат большого значения не имеет, а вот наличие pageant как раз имеет значение, и ssh реализовать функционал pageant не может никак, откуда и интерес именно к putty. Может быть получится запускать rsync с учётом путтевских запросов — есть минимум одно решение для этого, утилита cygnative.exe, но работает не очень надёжно и не всегда.

        Остаётся один вопрос — если у меня 500 директорий в проекте, то насколько быстро будут изменения в них отражаться на сервере? Не всех сразу, а одного файла в одной из них.
        • 0
          В принципе, вместо ssh.exe можно подсунуть SSH-клиент от PuTTY, но я не пробовал. И наверняка там опции командной строки другие. Да, пароль на ключи не поддерживаются.

          Насчет 500 (или 50000) директорий — изменения будут отображаться моментально, сколько бы ни было файлов и директорий. Потому что используются нативные средства ОС для отслеживания изменений.
          • 0
            насчёт putty проблема более серьёзная чем параметры, проблема и решение описаны в diario.beerensalat.info/tags/plink/, иногда у меня оно работает, иногда нет.
      • 0
        … забыл еще одну проблему у WinSCP, кстати — касается блокировок
        1. Он папки держит (держал?) заблокированными. Т.е. я не могу ее удалить, если она отсинкалась — винда говорит «папка используется, удалить не могу».
        2. Если у вас есть там, например, excel-файл или csv даже, и вы открываете его в Excel, то на Ctrl+S в Excel WinSCP этот файл передавать не будет — он будет ждать, когда Excel его «отпустит» (в свое время именно это меня сподвигло на написание RealSync-а, т.к. в проекте существенно использовались excel-файлы в качестве одного из источников метаинформации для кодогенерации «на лету»).
        • +1
          Дмитрий, у меня как раз обратная ситуация.
          Пытался пару месяцев назад использовать realsync на Win7 — после запуска и синхронизации он лочит файлы и не дает их переименовывать (пример: при запущенном realsync в проводнике создаем файл — создается. Пытаемся переименовать — не дает).

          Пришлось верстальщику жить с winscp, а ему бы realsync подошел очень…
          • 0
            Ух ты. Вы только что баг в Проводнике поймали. Файлы реально никто не держит — это видно по procmon-у хотя бы, а также потому, что они переименовываются везде, кроме Проводника. Попробую обойти эту проблему.
          • +1
            А, нет, извиняюсь, такой эффект при переименовании наблюдается только для файлов, находящихся в корневой папке. Проводник тут не виноват, я сам директорию открывал не в том режиме. Проблема исправлена, обновитесь (поменялся файл notify.exe), см. коммит github.com/DmitryKoterov/dklab_realsync/commit/ec31f68b44eddbe684b67c8cb17b34a76b9fd36d.
      • 0
        Как можно явно указать путь к ключу? Например, вагрант хранит ключ в .vagrant/machines/default/virtualbox/private_key, хотелось бы его использовать вместо создания отдельных для realsync
  • +2
    ох мега спасибо за тулзу! в нашем проекте на 10к+ файлов можно билдится только на нашем билд сервере и самба уже достала своими выкрутасами… а учитывая, что корпоративный стандарт — винда, а билдим мы *nix софт, то нам просто кость в горле синхронизация меж станциями разработчиков и билд сервером. Уже собирался писать свою утилиту, а тут такое прекрасное решение как надо!

    Не слушайте комментаторов говорящих «а нафиг оно надо»… очень надо когда у тебя 10+ девелоперов, проект на 10к файлов, периодические билды, рабочая и билд система имеют разные ос… просто у людей либо маленькие проекты, либо совершенно иные условия… Спасибо будем юзать. =)
  • +1
    тема! аналоги не пробовал, но эта тулза мне по душе. работая в офисе использовал sshfs так как инфраструктура позволяла — dev серевер стоял в соседней комнате в одой подсети. а вот при работе из вне, sshfs работал как таможня какая то, приходилось руками по ssh rsync'ом заливать.

    но только я заупускал ее в консоли, натравлявая на папку проекта: realsync ~/path/to/project, вот notify в «трэй» чего то не получилось «ввинтить». как быть?
    • +1
      сорри, я был не внимателен, трэй только для виндз
  • 0
    Да, к сожалению, и Samba, и SSHFS, и NFS не обладают достаточным функционалом кэширования для того, чтобы не тормозить при их таком использовании (хотя вполне могли бы). Насколько я знаю, сейчас еще не существует сетевой файловой системы с кэшированием достаточного уровня — везде полумеры.
    • 0
      Убунтовский gvfs поверх ssh работает так. Ctrl+S + Alt+Tab + F5 точно успевает на небыстром интернете.
      Конечно, имеет ряд проблем. Иногда крайне критичных.
      Спасибо за работу, не представляю, как люди через git это проворачивают. Сам раньше использовал bitbucket в качестве промежуточного звена.
      • 0
        Я имел в виду не скорость Ctrl+S + Alt+Tab + F5 (она будет хорошей на любой сетевой FS), а скорость поиска по файлам проекта, скорость локального коммита в Git и т.д. Т.е. с массовыми операциями с файлами все сетевые FS справляются относительно плохо.
  • 0
    Не совсем понимаю зачем это нужно, если есть сам rsync (и cwRsync на Windows).

    В Eclipse очень легко настраивается еще один билдер, который запускает rsync при сохранении файла и все работает как часы.
    • 0
      Как очень тормозные часы — задержка при запуске RSYNC в Windows будет около 5-6 секунд на проекте с 10000 файлами (да и с 10 файлами будет секунды 4 все равно — на Windows RSYNC медленный; на Linux будет побыстрее, но при условии хорошего канала). Очень неудобно ждать на каждый чих столь долго. Вообще, все это описано и в статье, и в комментариях уже несколько раз — пошли по четвертому кругу.
      • 0
        У меня при тысячах файлов задержка не болеее 1 с. (Windows 7 -> Ubuntu VM)
        • 0
          Для справки: при 10000 файлах в проекте RSYNC из Windows в Linux гоняет по сети туда-сюда порядка 200 килобайт даже при холостом запуске, когда ничего не изменилось. Кроме того, на просто старт RSYNC уходит порядочно времени — у меня около 2-3 секунды (NTFS, SSD, Windows Vista). Я очень рад за вас, что у вас в этих условиях все работает быстро.
  • 0
    Тем более что в phpStorm, например, поиск по всем локальным файлам даже очень большого проекта работает ощутимо быстрее grep-а и занимает 1-2 секунды (как они этого добились — для меня загадка; видимо, индексируют что-то заранее).

    Скажу больше, индексы есть и хранятся локально, т.ч. поиск работает так же замечательно и для проектов на самбе.
  • 0
    Такое пожелание. У меня в каталоге на сервере, помимо копий файлов с домашней машины, имеются ещё несколько симлинков на другие ресурсы, необходимых для нормальной работы скриптов. Может быть это плохой стиль, может быть нет, но это так. Реалсинк, разумеется, эти симлинки трёт, поскольку на домашней машине их нет. Соответственно, было бы здорово, если бы в конфиге можно было указать пути на сервере, которые игнорируются при репликации.
    • 0
      Это не принципиально, просто пожелание.
    • 0
      Так можно же. Укажите их.
  • 0
    Замечательная программа, вот только мне не хватает все же возможности получать измененные данные со стороны сервера, вариант исключения определенных папок из синхронизации не устраивает.
    • 0
      Вы уверены, что вам это действительно нужно? В статье про это есть, в комментариях про это обсуждали, плюс в README realsync-а описаны подробности, почему это может быть НЕ нужно на самом деле (хотя кажется, что нужно).
      • 0
        Постоянная обратная синхронизация действительно пожалуй не нужна, но все же часто требуется сделать upload папки с обновившимися скриптами.
        • 0
          А вы читали выше перечисленное? Откуда они возьмутся, эти обновившиеся скрипты, если вы все правки делаете на локальной машине?
          • 0
            Это если отсутствует система обновлений, или если не создаются новые файлы в процессе работы программы, не всегда есть возможность их локализовать в одном месте.
          • 0
            Скрипты не скрипты, а вот логи, например, иногда хочется посмотреть никуда с IDE не переключаясь. Или файлы зааплоаженные. То есть то, что приложение создало. Попробовал из другой консоли rsync обратный сделать — сработало, но как-то есть опаска, что в некоторых ситуациях может себя неожидаемо с первого взгляда повести.
            • 0
              А зачем у вас скипты аплоадят файлов и пишут логи в ту же директорию, где располагаются исходники? Это потенциальный источник проблем в будущем.
          • 0
            Переключили ветку в том же гите или прошлись sed'ом по файликам. Только не говорите, что IDE может сделать то же, что и sed.
  • 0
    А ведь можно шарить папку на машине разработчика и монтировать ее на сервере. Зачем сторонние тулзы? Неужели быстрее?
    • 0
      Обратный шаринг — идея остроумная, и я ее тоже в свое время пробовал. К сожалению, когда вы сидите не рядом с сервером, задержки все равно оказываются велики, но на этот раз все даже хуже — если у вас в проекте при запуске страницы подключается, например, 30 PHP-файлов с удаленного ноутбука, начинаются жуткие тормоза. Не говоря уж о проблемах при нестабильности связи.
  • 0
    Было бы очень удобно добавить следующие функции:
    • Настройка репликации. Например, не реплицировать определенный папки в дереве. К примеру папку кэша. Или файлы по маске. К примеру, svn/git.
    • Синхранизация с сервером. Единовременное скачивание с сервера всего дерева файлов на клиент по запросу пользователя. Т.е. репликация в обратную сторону с сохранением фильтров репликации. К примеру, программист ведет разработку с разных компов. Дома и с работы. Поработав на работе, он приходит домой, нажимает кнопку синхранизации и получает у себя на компе свежее дерево файлов с которым можно работать
    • 0
      1. Можно же настраивать исключения, см. конфиг-файл .realsync (директива exclude). Кстати, svn, git, cvs и еще много всего там по умолчанию уже в исключениях.
      2. Это не задача realsync, про это есть в англоязычной документации рассуждения. Для поддержания идентичности файлах на нескольких рабочих машинах используйте, например, dropbox или систему контроля версий.
      • 0
        Ок. Спасибо!
  • 0
    Есть такой нюанс (баг?), что когда сохраняешь под тем же именем картинку (проще говоря — редактируешь), то realsync её сразу не подхватывает — помогает переименовать её во что-то, а потом вернуть обратно. Это всё-таки баг или техническая особенность?
  • 0
    realsync делает синхронизацию раза в 2-3 быстрей нежели phpstorm. но вот usability issue:
    — я работаю в macos x
    — запускаю ide
    — запускаю консоль и realsync <app_path>

    вопрос: есть ли способ приучить запускаться (и останавливаться при закрытии) realsync вместе с phpstorm на определенном проекте?
    • 0
      в macos 90% проца сжирает. У вас как?
      • 0
        Коммент мой конечно очень запоздал, но такая же проблема. Если вдруг решили — откликнитесь?
        • 0
          Пришлите, пожалуйста, скриншот top, где видно, какой именно процесс сжирает, а также что при этом пишется в консоли realsync. Не должно такого быть. (А кстати, вы сделали chmod +x на файле notify, как пишется в инструкции по установке?)
          • 0
            Рад быстрому ответу:) Вот скриншот: d.pr/i/9kak
            в консоли: d.pr/i/UEIv
            notify исполняемым сделал. единственное в чем мог ошибиться — я его в дирректорию с realsync поместил
            • 0
              Ну его надо было оставить там, где он лежал, ./bin/darwin/notify — иначе realsync его не найдет просто. Там вот такой код:

              sub get_notify_daemon_cmd { my $bin = $BINDIR . '/bin/darwin/notify'; return if !-f $bin; die "ATTENTION! You must perform:\n chmod +x '$bin'\nto work with RealSync. Please do it now.\n" if !-x $bin; my $cmd = '"' . $bin . '" "' . main::cfg("local") . '"'; return $cmd; }

              Он вообще работает в фоне у вас сейчас?
              • 0
                sub get_notify_daemon_cmd {
                	my $bin = $BINDIR . '/bin/darwin/notify';
                	return if !-f $bin;
                	die "ATTENTION! You must perform:\n  chmod +x '$bin'\nto work with RealSync. Please do it now.\n" if !-x $bin;
                	my $cmd = '"' . $bin . '" "' . main::cfg("local") . '"';
                	return $cmd;
                }
                
                • 0
                  Да, точно, проблема была в том, что notify не находился. сейчас cpu не грузится сильно. 1-3% одного ядра.
                  Спасибо!
        • 0
          Да. Вам нужно запускать его так: perl /Users/nikolay/Downloads/dklab_realsync/realsync /path/to/project
          Тогда у вас должен появиться процесс notify.
  • 0
    А можно сделать так что-бы он при старте не затирал на сервере файлы без моего согласия? и не синхронизировал прямо таки все.

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

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

    Итого:
    1 — Хотелось бы делать синхронизацю конкретного проекта по требованию, но при этом что бы мониторинг был над всеми проектами, и быстро стартовать без синхронизации.
    2 — Перед тем как что то удалить, спросить моего мнения, и хотелось бы как то запретить удаление в некоторых папках например, но разрешить репликацию.

  • 0
    >> При этом используется SSH-соединение

    А, есть ли возможность использовать не SSH, а к примеру FTP для закачки?
    • 0
      Увы, это невозможно: ведь для начальной синхронизации используется rsync, он работает только через SSH.
  • 0
    Вероятно это не связано с RealSync, но так как я не администратор — не могу пока найти решение проблемы, может подскажете:

    • Для хранения сайтов я на сервере создал от пользователя root директорию /www/project
    • Создал группу webdev, добавил в неё пользователя fog, от которого хожу через RealSync.
    • Поставил директориям (www и /www/project) группу webdev и группе дал права rwx — clip2net.com/s/5oZ1uI

    Что получается:

    Файлы синхронизируются, т.е. по крайней мере попадают в директорию, но в консоли такая ошибка (в цикле):

    *****
    rsync: failed to set times on "/wx/test/.": Operation not permitted (1)
    
    sent 4267 bytes  received 55 bytes  2881.33 bytes/sec total size is 688926  speedup is 159.40
    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1039) [sender=3.0.6]
    [11:25:55] Rsync exited with code 23, retrying...
    [11:25:55] Detected changes in more than 10 objects. Running rsync: it's faster.
    
    sending incremental file list
    ./
    rsync: failed to set times on "/wx/test/.": Operation not permitted (1)
    
    sent 4267 bytes  received 55 bytes  2881.33 bytes/sec total size is 688926  speedup is 159.40
    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1039) [sender=3.0.6]
    [11:25:56] Rsync exited with code 23, retrying...
    [11:25:56] Detected changes in more than 10 objects. Running rsync: it's faster.
    
    sending incremental file list
    ./
    rsync: failed to set times on "/wx/test/.": Operation not permitted (1)
    
    sent 4267 bytes  received 55 bytes  2881.33 bytes/sec total size is 688926  speedup is 159.40
    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1039) [sender=3.0.6]
    [11:25:57] Rsync exited with code 23, retrying...
    [11:25:57] Detected changes in more than 10 objects. Running rsync: it's faster.
    *****


    Если поставить other — rwx — не помогает
    Помогает только если поставить директории owner — fog, но не хотелось бы этого делать, т.к. хотелось бы добавить и других пользователей.

    Как бы это исправить?
    • 0
      Ну так это стандартный rsync ругается, а не realsync. Я думаю, чтобы иметь право устанавливать атрибуты объекта (например, время последнего изменения у директории), надо быть владельцем этого объекта. А у вас владелец — root. Вот rsync и ругается.
      • 0
        Ну, да, я так и понял, что это не проблема самого RealSync, об этом и написал -)
  • 0
    Более года пользовался этой замечательной утилитой и столкнулся с проблемой после установки на рабочий компьютер Криптопро, его плагина для браузеров и Рутокена. Проблему описал в issue github.com/DmitryKoterov/dklab_realsync/issues/26

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.