На прошлой работе я как-то не озаботился отдельным компьютером на рабочем месте, а вместо этого таскался с ноутбуком между домом и работой. На нынешней же решил, что компьютер мне нужен, и тут-то меня и настигли мысли о штуке под названием "синхронизация".
Очень гладко прошла самая первая синхронизация. И на ноутбуке, и на рабочем десктопе у меня одна и та же Ubuntu, поэтому достаточно было простого копирования домашней директории с одного компьютера на другой, чтобы получить ту же среду, что была дома.
Дальше я стал думать над тем, как бы обеспечивать постоянную синхронизацию всяких букмарков, пары почтовых папок, to-do листа (который у меня так и прижился в виде файла на десктопе)... "Думать над" на самом деле переводится как "думать над тем, как бы не искать и не пробовать кучу написанных средств, а сразу бы получить в голове оформленный правильный способ" — не люблю я испытаниями софта заниматься :-)
Что странно, решение в голову вдруг как-то действительно пришло. Так сложилось, что у меня на хостинге есть subversion-сервер, который обслуживает мои программистские проекты. И я вдруг подумал, что синхронизация кода ничем не отличается от синхронизации всего остального по той простой причине, что практически весь юниксовый софт хранит свои настройки в виде отдельных файлов в home-директории.
Так, в итоге, и сделал. Сейчас синхронизирую:
- bookmarks.html из Firefox'а
- пару Django-рассылок из Thunderbird'а, который хранит почтовые папки в виде файлов
- Desktop/To do
- папку с файлами и презентацией для РИТа
Другими словами, синхронизировать я могу информацию любого рода, subversion'у это совершенно все равно. Причем я от него "бесплатно" получаю бэкап, историю, и еще сжатие при передаче по сети. В общем, доволен до жути :-). Перед перемещением из дома на работу и обратно пишу "svn commit", после перемещения — "svn up". Подумываю оформить это в виде гномовского апплета, чтобы терминал не запускать.
P.S. Я конечно не рекомендую это решение всем подряд уже хотя бы по той причине, что не у всех под рукой есть subversion-сервер.
Комментарии: 31
Ещё и версии хранятся. :-)
А так для синхронизации можно rsync использовать.
http://www.conduit-project.org/
Ну и rsync конечно же (=
Грамотно :)
А я как-то, специально для задач бэкапа/синхронизации/разработки, убрал безголовый сервер в кладовку, снабдил его демоном VPN и Samba. Теперь изо всех точек Internet есть доступ к файловому архиву и прочим домашним сервисам :)
А еще есть чудная вещь ifolder (http://www.ifolder.com)
Программистское решение (=
Нормальное решение. Самое то.
По поводу todo:
http://www.codeproject.com/tools/ToDoList2.asp
и в init.d прописать автоматический запуск svn ci/up :D
Это забавно конечно но вряд ли удобно.
Автору стоит взглянуть на расширения для firefox
http://www.google.com/tools/firefox/browsersync/
(автоматическая синхронизация букмарков)
и http://google.com/notebook/ (удобно для коротких заметок)
Неделя показывает, что очень удобно. Главный смысл в том, что это универсальное средство, которое не заставляет меня помнить о нескольких путях синхронизации разных вещей и не заставляет меня привычки (я привык к своему To Do, а не к Google Notebook).
Тебе постоянно нужно не забывать коммитить. Это неудобно.
Я не могу предложить способ лучше, правда...
Способы есть, в общем-то. Например упомянутый выше ifolder проводит синхронизацию постоянно. Мне, в общем-то, тоже ничто не мешает запихать синхронизацию в cron, чтобы это происходило само.
С другой стороны, ничего особенно страшного в забывании закоммитить нет. Ну посидел бы я сегодня без нескольких писем, которые дома принялись. Потом бы слил их вместе с помощью все того же subversion'а. Просто, раз уж была возможность попросить тебя коммит сделать, почему бы не воспользоваться :-)
Мне это кажется крайне неудобным, потому что я ненавижу svn mv (а люблю ручками иконки таскать).
По мне так лучше простой советский rsync (пускай и без истории).
В крон запихнуть - идея хорошая, да. Но тут такой момент. Когда ты работаешь дома с компом у тебя как правило открыты почтовик и браузер. То есть происходит работа с файлами, которые надо коммитить. Коммит пройдет в такой ситуации?
Хотя, в принципе, можно повесить коммит на что-нибудь вроде закрытия почтовой программы.
в крон идея не очень хорошая, в init.d - гораздо правильней.
ээ. с bookmarks.html, никакой работы не происходит. т.е. происходит но шанс попасть в такой момент ничтожно мал да и ничего не случиться страшного.
с почтой - можно смотреть на наличие файла .lock или типа того.
если положить скрипт в init.d такой проблемы нет в принципе.
а ещё лучше - не удалять письма при забирании почты по pop(пока их не убил в inbox-есть такая функция)/использовать imap.
а для файрфокса - foxmarks.
todo классные в eclipse - автоматически подхватываются #TODO blabla из кода, при щелчке открывается соотв. файл на нужной строчке.. ну и всё такое
ещё идея-просто хранить закладки и прочее в разделе примотрированном по sshfs -)
история тут имхо и правда не нужна
Можно синхронизировать не только закладки, но и всю информацию в браузере. Я писала об этом и о синхронизации в целом: http://engelside.net/sync-yourself/
спасибо за статью, мысль была нопока до реализации синхронизации и централизованного хранилища руки не дошли...
можете по побробней описать Вашу структуру работы с SVN не сам принцып работы :) а вот то как оно у Вас работает:)))
ибо хочу и себе, пока для синхронизаций использую Unison как ГУИ так и консольную... но вопрос с бекапом и версиями стоит остро
спасибо заране за ответ, успехов Вам в ваших делах
ЗЫ
с удовольствием читаю Ваш блог, ибо мой никто не читает:)
Для "синхронизации" почты я использую IMAP
Очень удачное решение. Я уже больше года храню все важные для меня документы в Subversion — в высшей степени доволен, особенно историей и простотой организации бэкапа.
эх синхронизация - это уже давно головная боль. Количество техники, информацию на которой хочется синхронизировать, растет очень быстро (хотя поток информации, безусловно быстрее). И если синхронизация рабочих файлов между пк на работе и дома например действительно решается при наличии у вас собственного svn репозитория, то в области синхронизации более специализированной информации - от todo до закладок в браузере - все совсем не так праздно.
И вот приведенный browsersync действительно не плох, но, увы, работает он не идеально, а если по каким-то причинам пользуешься на разных машинах разными браузерами, то этот вариант отпадает. Notebook - также все бы неплохо, но реализация не дотягивает до того же firefox'ового scrapbook - а без оффлайновой доступности заметок толку от них мало, хотя по-моему api к нему есть - надо бы посмотреть его.
Todo , заметки, контакты, календарь - это конечно еще большая проблема - потребности в их доступности не ограничиваются пк - они должны быть в режиме 5-секундной готовности - и когда у меня появляется какая-то задача или мысль, я должен быстро ее внести и делать это я буду КПК (да - кто-то иной на телефоне - не суть), и вот тут я никак не обойдусь текстовым файлом - при том что эту задачу я потом хочу увидеть на большой машине.
А ведь еще нужна возможность видеть в приложении к задачам все письма, ссылки, сообщения и пр. Да и синхронизацию хочется всего этого иметь не просто между устройствами, а с неким репозиторием, в качестве которого могли бы выступить множество web-приложений (выполняя к тому же функцию доступности информации со случайных машин).
А еще есть такой вопрос как кросс-платформенность на уровне ОС и пр. и пр. В общем на задачах синхронизации можно было бы не один startup поднять - найти бы время.
Для архивирования сейчас использую rdiff-backup. Его, в принципе, можно использовать и для синхронизации. Преимущество перед svn одно:
Вообще-то для FF есть шикарный гуглевский плагин, который синхронизирует через ихний сервер не только букмарки, но и пароли, текущие куки, открытые закладки и пр.
про отличшнейший google browsersync уже пару раз сказали, я хочу упомянуть про другое решение с использованием subversion - сам в данный момент разбираюсь с WebDAV - и судя по всему это именно та технология которая нужна - версионное хранение файлов на сервере, но пр этом она скрывает от пользователя все лишние телодвижения вроде svn commit/update. Технологически все это настраивается на apache-сервере и пользователем видится как обычная папка в файловой системе, а на серверной стороне стоит svn-backend который делает commit при закрытии файлов.
я сам пока только разбираюсь с этой технологией и использовать ее не пробовал, но потенциально очень интересно (например хочу попробовать использовать для хранения документов на предприятии).
нашел маленькую howto по установке:
http://www.hss.caltech.edu/help/unix/admin/web/apache-webdav-xp
Я уже полгода как весь свой $HOME завёл в систему контроля версий.
А для todo пользуюсь http://todotxt.com/
(Там есть возможность скачать джаббер-бота. Вот он-то у меня в сети и торчит постоянно.)
будет неприятно если где-нибудь в $HOME попадет бара больших файлов.
Неприятно не будет, потому что хоть корень репозитория и совпадает с home, файлы к нему приписываются не автоматически, а только если "svn add" сказать. Иначе бы это было просто нереально.
Мои 5 копеек давно думал над этой проблемой только у мне все хуже :-) приходится сидеть под виндой в силу работы и того что моно ну никак не может догнать дот нет. :-))) На компе стоит http://tortoisesvn.tigris.org/ очень удобно прямо в эксплорере есть возможность работать с svn. Репозитарий храню на https://opensvn.csie.org/
А в папочке у меня стоят на http://portableapps.com/. Прихожу домой синхронизирую.
Да и иногда удобно репозитарий на юсб скидывать
2hodza
тогда вместо subversion нужно использовать использовать распределенную систему контроля версий. Например, bzr.
28.
Всё-таки rsync для этой задачи подходит куда лучше. Тем более с версиями и incremental апдейтами. Для последнего надо linux + любую fs которая поддерживает hard links:
1) первый бекап делает простое что то вроде abc-back-DATE/ и симлинк current на него
2) перед каждым последующим копируем current в abc-back-NOWDATE/ но не копируем физически, а просто жесткие ссылки расставляем (места займёт кол-во файлов * размер блока. Т.е. мало)
3) rsync отправляем на синхронизацию с новым abc-back-NOWDATE. Т.к. там лежит полная копия abc-back-DATE/ то rsync перепишет только изменения. В результате будет две папки abc-back-DATE и abc-back-NEWDATE. Не забываем поставить новый симлинк на current.
Пример результата:
Самое весёлое - при удалении самого старого архива, физически все равно ведь ничто с винта не сотрётся, до тех пор пока хоть что-нибудь жесткими ссылками ссылается в последующих бекапах.
Для локальных бекапов это вообще perfect решение. Для удалённых - перед бекапом (т.е. перед самим rsync) надобно ещё запускать удалённо скрипт-приготовлялку.
Локальные бекапы я целиком автоматизировал, скрипт могу выложить если кому интересно.
Сжимать такие штуки можно только целиком, т.е. все бекапы сразу. Расжимать, соответственно, тоже - только целиком и перед каждым бекапом. Дело в том что tar хардлинки в себе тоже нормально держит. Но вычислительных мощностей все равно требуется не мало. Как вариант - я вообще бекапы положил на reiser4 loop-овый, со включенным gzip сжатием. Перед бекапом - маунт, после - анмаунт. Потому что оставлять надолго подключенный reiser4 все же опасно - у меня упса нет =).
Follow-up к предыдущему комменту: хоть бекап и incremental - разворачивается любой из бекапов простым копированием 1 папки. Т.е. хардлинки там уже все расставлены. Т.е. сворачивать обратно rsync incremental не надо (как это бывает если делать простые инкрементивные бекапы).
Гид по всему этому барахлу в инете есть, но слишком старый и без конкретики.