Аналог Dropbox, только свой и в том числе для git-репозиториев

Разные случаи, может что-то из: sparkleshare / dvcs-autosync / git-annex подойдет.

ftp/ssh/smb/nfs/webdav/etc + fuse

ftp/ssh/smb/nfs/webdav/etc + fuse

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

Смотрю на syncany. Кто-либо имел опыт с ним?

Блин, оно использует гит внутри себя. Ехал git через git...

Аналог Dropbox

Блин, оно использует гит внутри себя

/0

Ну понимаешь, засовывать репозиторий git в другой git матрешкой — мягко говоря, некошерно.

Может посмотреть в сторону обвязок над rsync: вроде unison умеет автоматом обновлять.

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

SparkleShare

Блин, оно использует гит внутри себя. Ехал git через git...

В SparkleShare ты заводишь сколько хочешь git-синхронизированных каталогов а ля Dropbox. Т.е. на каждый git-проект — отдельный каталог.

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

github/bitbucker + cron/init-script?

может какой свой btsync поднять?

Мне надо, чтобы не было мусорных коммитов самой синхронизации

Как ты представляешь коммит изменений в git без коммита? :)

трудно перед началом работы сделать git pull? а в конце работы сделать git push?

Я не хочу, чтобы система синхронизации делала коммиты якобы от меня. Это может быть совершенно нерабочий код на середине чего-то там. Я что — мальчик на побегушках, чтобы потом за машину ребейсить это говно? Мне что — совсем заняться больше нечем?

То есть, с одной стороны, у меня проект в git. И он же под синхронизацией. Я делаю в git свои коммиты. Во что там делает коммиты синхронизилка — дело сугубо ее, но коммитить именно в мой репозиторий ей нельзя.

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

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

трудно перед началом работы сделать git pull? а в конце работы сделать git push?

А что, если я посредине чего-то, чего даже коммитить не хочу пока что? А ты тут разводишь вообще push, pull и shared history во все поля.

Я не люблю коммиты без начала и конца.

Я не хочу, чтобы система синхронизации делала коммиты якобы от меня. Это может быть совершенно нерабочий код на середине чего-то там.

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

промежуточное коммить в другую ветку.

Я еще и помнить об этом должен. 21-й век, етить за ногу.

Короче, решение наметилось, как буду не такой злой и замученный, отпишусь.

Ключевой момент — оно однопользовательское и предполагает, что над одним и тем же каталогом одновременно работается только из одного рабочего места (чего мне хватает за глаза).

Запросто. Запускай rsync по крону. Только тебе нужен будет один централизованный сервак, к которому будет доступ для всех остальных компьютеров.

Я не люблю коммиты без начала и конца.

А вот зря. Я тоже не люблю. Но как стал свои велосипеды на гитхаб переносить, обнаружил, что в трех (а то и больше — уже не помню) были изменения, но не было коммитов. И хрен поймешь: нужные это изменения, или так — поигрался и решил вернуть все взад...

А что, если я посредине чего-то, чего даже коммитить не хочу пока что?

Я обычно отправляю себе на почту патчик. С stgit это работает почти прозрачно.

А hg вообще может запушить стопку патчей.

Где-то так, но не по крону. Опишу, только надо переезд завершить.

Так это как раз и есть следствие «без начала и конца».

У меня обычно так, что можно всегда сказать, занафига был сделан данный коммит, но это никогда не «продолжение работы, начатой в предыдущих пяти коммитах», и чтобы код взлетел вообще, нужны все шесть. То есть, каждый из них — какая-то самостоятельная более или менее единица работы.

Для этого иногда нужно коммитить чаще и больше.

А то, что нужно мне, как раз для экспериментов вида «хз что будет, надо поглядеть». И в коммит не забросить, и выкидывать не хочется, и руками синхронизировать геморройно. Кто знает, вдруг завтра осенит еще лучшая идея, или вообще все нахрен надо выкинуть?

btsync попробуй

Почему owncloud еще не сказали?

А еще rsync демона можно попробовать приручить.

Вот же JetBrains как раз такую dvcs делает: https://www.youtube.com/watch?v=PR8BhFv9KAU

Вот же JetBrains как раз такую dvcs делает

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

https://bitbucket.org/

самое то

ордам мартышек не нужно знать про историю

Что имеется ввиду? Там же просто поверх обычной истории хранится состояние рабочей копии в mutable changeset, которое умеет синхронизироваться.

Что имеется ввиду?

web-based gui как основной способ работы.

Так что за решение, так и не отписал...

Забыл :(

Понятно, я сейчас пилю проект в этом направлении. Syncany в этом плане интересное решение, единственно осталось продумать, как это совместить с git'ом и прочими полнофункциональными vcs, чтобы не перекидывать лишние данные.

Bittorent sync? Даже на мобилках.