LINUX.ORG.RU

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

 


1

2

Меня вот что интересует.

Есть вот такая штука, как Dropbox. Все бы в ней хорошо, но она известна тем, что git-репозитории в ней довольно быстро превращаются не то что в тыкву, а в тыквенное пюре, после которого никакой git fsck не спасет.

Ну и тот факт, что меня может пасти какое-нибудь КГБ, не говоря уже о той ситуации, когда можно было с любым паролем поиметь в аккаунт кого угодно, не добавляет радости.

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

И чтобы на своем сервере + в локальной сети можно было.

Нет такого, что ли?

★★★★★

Последнее исправление: CYB3R (всего исправлений: 1)

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

anonymous
()
Ответ на: комментарий от arkhnchul

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

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

shimon ★★★★★
() автор топика
Ответ на: комментарий от anonymous

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

shimon ★★★★★
() автор топика

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

anonymous
()
Ответ на: комментарий от shimon

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

anonymous
()
Ответ на: комментарий от shimon

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

shimon ★★★★★
() автор топика

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

spichka ★★★
()
Ответ на: комментарий от shimon

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

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

KRoN73 ★★★★★
()

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

bvn13 ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

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

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

shimon ★★★★★
() автор топика
Ответ на: комментарий от bvn13

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

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

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

shimon ★★★★★
() автор топика
Ответ на: комментарий от shimon

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от bvn13

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

shimon ★★★★★
() автор топика

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

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

shimon ★★★★★
() автор топика

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от shimon

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

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от shimon

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

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

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

baverman ★★★
()
Ответ на: комментарий от Eddy_Em

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

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

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

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

shimon ★★★★★
() автор топика

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

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

KennyMinigun ★★★★★
()
Последнее исправление: KennyMinigun (всего исправлений: 1)
Ответ на: комментарий от kamre

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

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

baverman ★★★
()
Ответ на: комментарий от baverman

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

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

kamre ★★★
()
Ответ на: комментарий от kamre

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

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

baverman ★★★
()
24 июля 2014 г.
Ответ на: комментарий от shimon

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

foror ★★★★★
()

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

umren ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.