Сначала это был SVN (с CVS, делающим второстепенное представление). Тогда это был Git (с Mercurial, говорящим: «Посмотри на меня! Посмотри на меня!»), и теперь git кажется Золотым стандартом. Но может ли этот проект на основе rsync все это перевернуть? Я проверил это в эти выходные, чтобы решить.
Если вы выполните DuckDuckGo search for jamsync, вы увидите множество ссылок, говорящих о музыкальном продукте. Вы занимаетесь программным обеспечением, так что, очевидно, вы здесь не поэтому. Итак, сайт, который вы ищете, — jamsync.dev.
Автор (Zachary Geier) включил небольшое демонстрационное видео, демонстрирующее новые яркие функции. Они на самом деле крутые. Даже в двухминутном видео некоторые начальные особенности были:
jamбуквально единственная команда и не содержит опций. Эта единственная команда отвечает за отправку и извлечение в/из удаленного репозитория и отслеживание изменений, отправленных в удаленный.- Используя
jam, исходный файл автоматически обновляется, если есть изменения в восходящем направлении. - Удаленный репозиторий содержит замечательную функцию, позволяющую контролировать версии.
- Самое главное, бэкенд использует rsync
Если вы не знакомы с rsync…
Допустим, у вас есть 2 компьютера и вы хотите передать файл с Хоста 1 на Хост 2. В современном 21 веке есть несколько способов сделать это:
- Отправьте файл себе по электронной почте, загрузите вложение.
- Загрузить в облачное хранилище. Продолжайте обновлять, пока не появится файл, загрузите его.
Наконец, если вы достаточно разбираетесь в технологиях, вы можете использовать такой инструмент, как scp или его усовершенствованный кузен rsync . Эти инструменты позволяют передать файл по протоколу ssh.
Из того, что я могу сказать, теория, лежащая в основе jamsync, заключается в том, что git был разработан слишком рано, чтобы использовать возможности scp или rsync, поэтому ему не хватает мощности этих протоколов, и вместо этого он использует свой собственный «gitty» вариант передачи ssh. Но теперь, когда у нас есть эти инструменты, мы могли бы также разработать инструмент, который их использует!
Пока все хорошо, давайте проверим этого плохого мальчика!
Маленькая жалоба
Я стараюсь сохранять позитивный настрой и оказывать поддержку, так что я нырну сюда, чтобы немного поругаться. Хотя проект находится под лицензией AGPL, это не так. На самом деле есть только один способ загрузить исходный код, и вы можете загрузить только последнюю версию. Нет документации о том, как его установить, внести свой вклад или зарегистрировать проблему. Я думаю, что для успеха проекта он должен быть более открытым и совместным.
Я подумал, может быть, у Зака есть репозиторий на jamsync.dev. Не то чтобы я мог сказать.
Опять же, просто улыбка нахмурилась… идем дальше!
Скачивание и установка
К счастью, двоичный файл — это просто отдельный двоичный файл. Не нужно устанавливать системные пакеты (хотя в настоящее время это доступно только для Mac и Linux — если вы не знаете, как установить WSL).
Предварительные требования
Если вы хотите попробовать, я бы порекомендовал зарегистрироваться на jamsync.dev. Регистрация довольно проста. Он не запрашивает ваш номер телефона, дату рождения, имя вашей собаки и т. д. Зак решил использовать 0auth — технологию, которую, по моему мнению, следует использовать большему количеству организаций.
Бег
Бег
$ ./jam
приводит к открытию веб-браузера, и в этом случае вам необходимо авторизовать приложение для использования вашей учетной записи (основной элемент веб-аутентификации).
Это мне тоже нравится. Больше не нужно загружать открытые ключи ssh в репозиторий.
Поскольку я не слишком вложился в проект с jamsync, я решил использовать текущий репозиторий. Если вы хотите полностью использовать jamsync, вам нужно добавить этот двоичный файл jam в каталог где-нибудь в переменной окружения PATH.
Как (отчасти) и ожидалось, он загрузил файлы в текущий каталог.
Теперь перейдите на jamsync.com, и вы должны увидеть свою электронную почту в верхнем правом углу. Нажав на нее, вы увидите свои репозитории.
Используйте ползунок соответствующего цвета, чтобы перейти к последней версии.
Давайте добавим несколько файлов!
Одно дело — случайно добавить существующие файлы в проект. Совсем другое дело создавать и обновлять новые файлы.
Чтобы проверить расширение проекта, я перемещу jam в каталог bin, как и предполагалось природой, и начну возиться с репозиторием.
Этот простой тест будет включать в себя:
- Создание отдельного каталога
funny2, который будет действовать как второй пользователь. - Создайте файл из
funny. - Измените файл в
funny2. - В файле должны быть соответствующие изменения.
Надеюсь, если я назову проект funny, это должно отразить изменения кода:
~/projects/sandbox/funny2 ᐅ jam 2023/01/22 14:07:59 This directory is empty. 2023/01/22 14:07:59 Name of project to download: funny 2023/01/22 14:08:44 Creating directories... 2023/01/22 14:08:44 Downloading files... 2023/01/22 14:09:07 Done downloading. 2023/01/22 14:09:10 Watching . 2023/01/22 14:09:10 Watching .jamsync 2023/01/22 14:09:10 Watching jam_linux_amd64.zip 2023/01/22 14:09:10 Watching jam_linux_arm64.zip
И это так! Я переместил файлы .zip из каталога и создал файл test.txt в funny2 . Я продолжал запускать ls и ждал, но не увидел изменения файла.
Затем я снова переключился на окно man jam и нашел виновника:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0x955060]
goroutine 1 [running]:
main.pull(0xc00022ca50, 0xc00022c5d0, 0xc000280f60)
/Users/zdgeier/Documents/jamsync-open4/cmd/client/main.go:273 +0x1c0
main.main()
/Users/zdgeier/Documents/jamsync-open4/cmd/client/main.go:183 +0x16b1
Мое имя пользователя не zdgeier, и я не использую Mac (если вы видите путь, начинающийся с /Users/, это указывает на файловую систему Mac. В UNIX/Linux домашний префикс — /home/). Похоже, Зак жестко запрограммировал путь.
Хотя, чтобы быть ясным, без суждений. Я делал это много раз.
Но давайте посмотрим, сможем ли мы реализовать настоящие «многопользовательские» изменения. Я снова запущу jam в обоих каталогах.
Когда я это сделал, как ни странно, файлы zip, которые я изначально переместил в исходный каталог проекта funny, снова появились в обоих (я думаю, он подхватил изменения в funny2 ).
Еще более интересно то, что test.txt каким-то образом получил разрешения на выполнение.
Во-первых, я попытаюсь избавиться от файлов .zip, переместив их из обеих папок.
funny> rm *.zip funny2> rm *.zip funny> ls test.txt funny2> ls test.txt
Все идет нормально. Он удалил файл из обоих.
Далее попробую сделать 2 модификации одновременно. В настоящее время test.txt содержит следующий текст:
Hello, World!
Поскольку синхронизация немного медленнее, чем операции с файловой системой, я буду одновременно изменять файлы с точки зрения сети, выполнив echo/pipe && echo/pipe :
$ echo 'Hello, Jupiter!' > funny/test.txt && echo 'Hello, Mars!' > funny2/test.txt
После проверки обоих файлов…
funny$ cat test.txt Hello, Jupiter! funny2$ cat test.txt Hello, Mars!
Не нужно быть детективом, чтобы увидеть, что ничего не изменилось. На самом деле, в терминале, где работает jam, похоже, что программа снова дала сбой:
2023/01/22 14:20:40 invalid argument ~/projects/sandbox/funny ᐅ
Что за неверный аргумент? Неизвестно, но я подозреваю, что это аргумент rsync.
Давайте запустим его снова, чтобы увидеть, какой файл синхронизируется первым.
~/projects/sandbox/funny ᐅ jam 2023/01/22 14:29:08 Uploading test.txt 2023/01/22 14:29:11 Uploading file list... 2023/01/22 14:29:15 Committed changes. 2023/01/22 14:29:15 Watching . 2023/01/22 14:29:15 Watching .jamsync 2023/01/22 14:29:15 Watching .test.txt.swp 2023/01/22 14:29:15 Watching test.txt # I'm not ending the program...it ends on its own... ~/projects/sandbox/funny2 ᐅ jam 2023/01/22 14:30:17 .jamdiff file found at test.txt.jamdiff ~/projects/sandbox/funny2 ᐅ jam 2023/01/22 14:30:30 .jamdiff file found at test.txt.jamdiff ~/projects/sandbox/funny2 ᐅ
Как видите, только одна сторона, кажется, наблюдает за изменениями. Другая сторона, кажется, обнаруживает файл jammdiff и сдается.
Пока (судя по видео) похоже, что пока поддерживается только однопользовательская джем-синхронизация.
Заключение
Является ли jamsync убийцей git?
Кто скажет? Известно, что люди плохо разбираются в технических прогнозах. В колледже я предсказал, что через 2 года у нас будут генетически модифицированные хомяки, которые будут приносить еду из фуд-корта по команде, но я выпустился до того, как это стало реальностью, и мой хомяк умер до того, как эксперимент получил полное финансирование.
Очевидно, что этот проект все еще находится на ранней стадии. Основная концепция джемсинка не так уж и ужасна. На самом деле поток действительно освежает. Git, кажется, из ушедшей эпохи, когда люди были отключены от Интернета 90% времени и выдвигали огромные коммиты, которые содержали недели изменений. Но мы живем в 21 веке, когда коммиты контроля версий происходят почти ежедневно. Почему бы не адаптироваться к этим изменениям?
В целом, я думаю, что для того, чтобы проект выжил и стал стандартом, джемсинк должен раскрыться. Используйте GitLab, пока jamsync не станет стандартом.
👉 Вам понравилась эта статья? Поделиться с тремя друзьями или коллегами?
📢 Комментарий ниже: как вы думаете, пришло ли время git? Готовится ли улучшенная система контроля версий?
💓 Подпишитесь на DamnGoodTech в Ко-Фай. Помогите поддержать больше этих статей.
🤝🏼 Наймите меня в качестве ведущего разработчика в вашу команду.
