sonata не рассмотрели...

rsync наше всиО,

сколько всего не пробовал все одно возвращаюсь к rsync

Полезно, очень полезно.

Неужели нету FOSS-аналога dropbox'а?

думаю, можно попробовать наваять что-то имея надстройку для наутилуса и Гит репозитарий :) Кто возьмется?

Лично я держу домашний каталог в subversion'е (и в гробу видал распределённые vcs).

>"Синхронизация вашей жизни"

Загоните его назад в психушку!

>Неужели нету FOSS-аналога dropbox'а?

Действительно нужная синхронизация. Git / Bazaar держать для фото-архива это жуть.

Вроде SuSE разрабатывает модуль для синхронизации home_dir пользователя. Есть Unison. Может Unison сможет заменить dropbox.

>Есть Unison

Вроде это из другой оперы.

унисон это вместо эксченжа и офисной АТС

> унисон это вместо эксченжа и офисной АТС

Разве? По-моему, Unison - достаточно простая вещь для синхронизации файлов. Проблема, правда, в том, что при синхронизации NTFS-Ext3 он у меня сошёл с ума над пермишенами :(

Я думаю, что rsync+inotify значительно лучше.

Собственно, скрипт-то тривиальный получится, что-нибудь вроде:

inotifywait ... | while read date time file; do
    rsync ${file} rsync://billy@example.com/backup/${file} && \
    echo "At ${time} on ${date}, file ${file} was backed up via rsync"
done

Или при помощи incron.

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

> Действительно нужная синхронизация. Git / Bazaar держать для фото-архива это жуть.

Реально жесть. У меня фотки и музыка никак не синхронизируются, хотя остальная часть хомдира лежит в svn'е. В конце концов я поднял себе Gallery2 и держу часть фоток там, а для музыки пока не придумал адекватного решения.

> Лично я держу домашний каталог в subversion'е (и в гробу видал распределённые vcs).

хехе, извращенец. git банально удобнее .

>Я думаю, что rsync+inotify значительно лучше.

>Собственно, скрипт-то тривиальный получится, что-нибудь вроде:

>inotifywait ... | while read date time file; do > rsync ${file} rsync://billy@example.com/backup/${file} && \ > echo "At ${time} on ${date}, file ${file} was backed up via rsync" >done

>Или при помощи incron.

>Вопрос только в том, кто будет предоставлять хостинг.

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

>В конце концов я поднял себе Gallery2 и держу часть фоток там, а для музыки пока не придумал адекватного решения.

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

>Я думаю, что rsync+inotify значительно лучше. >Собственно, скрипт-то тривиальный получится, что-нибудь вроде: >inotifywait ... | while read date time file; do > rsync ${file} rsync://billy@example.com/backup/${file} && \ > echo "At ${time} on ${date}, file ${file} was backed up via rsync" >done

При svn commit/update/checkout сколько раз запустится rsync, если в проекте 1000 файлов в 100 директориях? Ответ: будут синхронизированы 500 директорий и ~2000 файлов. 2000 запусков rsync это круто?

Я пользуюсь unison постоянно.
И для синхронизации исходников программ с фермой,
и для backupов статей и тп с ноута на рабочий комп
и обратно и тп. Очень нравится, что он очень простой,
легко позволяет разрешать конфликты и тп.

>При svn commit

Во-первых, можно запустить inotifywatch. Во-вторых, какой идиот будет синхронизировать внешними средствами директорию, которая итак в subversion?

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

>да любой идиот, который занимается разработкой программ.

Зачем? Нужно просто использовать нормальные системы контроля версий. В крайнем случае никто не отменял .ignore.

>Вообще код из примеров

Был приведён в качестве примера.

идеотизм в том, что в конце написали про Dropbox :-/ :-/ :-/

причём в добак ко всему скриншотами.. (а не командами консоли...)

остался неприятный остадок после прочтения :-(

>> Лично я держу домашний каталог в subversion'е (и в гробу видал распределённые vcs).

>хехе, извращенец. git банально удобнее .

git банально в десяток раз быстрее.

unison рулит для синхронизации и бэкапов.

> унисон это вместо эксченжа и офисной АТС

Привет от СтанаФон?

клиент серверная архитектура проще для понимания. git - сложнее для понимания. + нет нормальных средств под Win, кто знает, где и в какой системе тебе понадобятся твои данные. В общем с git сложно синхронизировать СВОЮ ЖИЗНЬ)))

Помнится, в git была возможность использования в режиме _нераспределенной_ VCS. Натыкался в мануалах.

А про вин - +1. TortoiseGit нужен.

Специалистам по всему: а можно mercurial настроить так, чтобы когда говорил hg commit версии сохранялись не только в текущей директории проекта, но и на другом диске. Именно для целей бэкапа.

> Помнится, в git была возможность использования в режиме _нераспределенной_ VCS.

Что конкретно такое "распределённое" вам мешает? Если забыть про push/pull, то получится как раз нераспределённая VCS, вы не об этом?

странно, почему не написали про юнисон - это лучшее решение

Мне распределенность не мешает - я ей и пользуюсь.
Я ответил человеку на его реплику.

>Что конкретно такое "распределённое" вам мешает? Если забыть про push/pull, то получится как раз нераспределённая VCS, вы не об этом?

Не... Нераспределённая - это когда push на один репозиторий при каждом ci, и pull только с -u :)

> хехе, извращенец. git банально удобнее

Фор хум хау. Вместо одного svn ci делать отдельный commit и отдельный push? Ну уж нет, спасибо большое.

> git банально в десяток раз быстрее.

Для ci - вполне возможно, но это для меня не критично. Для co - фиг там "в десятки".

> Что конкретно такое "распределённое" вам мешает? Если забыть про push/pull, то получится как раз нераспределённая VCS, вы не об этом?

Ну да, конечно, если забыть про push/pull. Если в слове "хлеб" сделать четыре ошибки, получится "пиво".

Вот лично мне удобно пользоваться централизованной vcs, и мой хомдир - не кернел с сотнями конкурирующих веток.

> Посмотри на gnump3d, что-то вроде галереи для музыки и видео.

Большое спасибо

Я так понял ето больше для аудио, а что -то такое для видео есть? Чтоб можно било инфу про видео добавлять, картинку и т.д.

Юзаю git для локальных проектов (т.е. репозитарий на том же компе). Соответственно push делать не надо.
По сравнению с ним SVN - такая тормозила.... Собс-но потому и сижу на git. Разница весьма заметна при ЛЮБЫХ операциях.

git

Ну раз уж речь зашла про git...

Я правильно понял, что в этой системе, в отличие от subversion, отсутствует понятие рабочей копии, и то, что я создаю у себя - это ещё один репозитарий, по сути идентичный источнику?

Unison идёт лесом, т.к. не умеет работать с Юникодными именами файлов. О том, что гениальный дизайн оного не предполагает backward compatibility (т.е. для работы нужен бинарник одной и той же версии в обоих концах) я уже и не заикаюсь.

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

Так что нет в жизни счастья. Я, для синхронизхации музыки с сервера на media PC с Вистой, остановился на ROBOCOPY между подмонтированным через SMB и локальным каталогами. Очень медленно и неоптимально (файлы сравниваются по метаданным и копируются целиком), но надёжно.

>Я правильно понял, что в этой системе, в отличие от subversion, отсутствует понятие рабочей копии, и то, что я создаю у себя - это ещё один репозитарий, по сути идентичный источнику?

По существу, да.

>Я правильно понял, что в этой системе, в отличие от subversion, отсутствует понятие рабочей копии, и то, что я создаю у себя - это ещё один репозитарий, по сути идентичный источнику?

Не совсем. Репозитарий хранится в подкаталоге .git проекта. А вот файлы твоего проекта - это рабочая копия. Только коммиты из нее идут в локальный репозитарий (.git), а не в родительский (называемый origin).

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

А есть ли в гите аналог удалённого svn list? К примеру, в svn, не создавая у себя рабочей копии (это важно) я могу посмотреть список веток в проекте:

svn list svn://foo.bar/branches/

Можно ли элегантно сделать гитом то же самое?

JackYF, Pavval: спасибо за ответы.

А ещё про синхронизацию музыки, хоть и в порядке шутки - http://kastaneda.livejournal.com/122815.html

Хочется найти аналог Novell iFolder :) хоть бери и покупай себе OWS от Новеля :)

> а можно mercurial настроить так, чтобы когда говорил hg commit версии сохранялись не только в текущей директории проекта, но и на другом диске.

man hgrc
на тему [hooks] commit

> unison рулит для синхронизации и бэкапов.

rm -rf * unison..

Отличный бэкап. Удалено на всех компах. Не нужно путать назначение.

Имелось в виду:
  rm -rf *
  unison.. удаляет на другом компе
Данных нет, бэкапа нет.

> А про вин - +1. TortoiseGit нужен.

Так есть же:
http://code.google.com/p/tortoisegit/