После трёх лет разработки доступен (http://bomahy.nl/wordpress/?p=171) первый стабильный релиз проекта SparkleShare (http://sparkleshare.org/), в рамках которого развивается свободный движок для создания собственных online-хранилищ, похожих на Dropbox, а также для обеспечения синхронизации данных между несколькими системами и организации совместной работы с данными. SparkleShare оформлен в виде графического приложения, написанного на языке С# с использованием Mono и библиотеки GTK+. Исходные тексты распространяется (https://github.com/hbons/SparkleShare/) под лицензией GPLv3. Готовые бинарные сборки подготовлены для Linux (Ubuntu, Fedora и т.п.), Mac OS X и Windows.<center><a href="http://80.77.87.121/wordpress/wp-content/uploads/2012/12/spa... src="http://www.opennet.dev/opennews/pics_base/0_1355144580.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>
Ключевой особенностью SparkleShare является использование в качестве хранилища стандартных Git-репозиториев, не требуя запуска серверного ПО и развертывания специальной серверной инфраструктуры. SparkleShare позволяет задействовать в качестве хранилища любой поддерживающий Git внешний хостинг или сервис, например, GitHub, Bitbucket, Gitorious или любой сервер, к которому имеется доступ по SSH и на котором установлен git. Доступ к данным также можно получить при помощи обычных инструментов git, без установки SparkleShare. Для анализа истории работы с файлами и отката изменений можно использовать средства версионного контроля. Иными словами, SparkleShare можно рассматривать как специализированный Git-клиент, оптимизированный для хранения и обмена файлами. Тем не менее, SparkleShare предусматривает (https://github.com/hbons/SparkleShare/wiki/Implementing-a-ba...) возможность создания бэкендов, позволяющих использовать другие типы хранилищ и протоколы для доступа к ним.
Несмотря на простоту и элегантность решения на базе Git, у подобного подхода есть отрицательные стороны. SparkleShare плохо подходит для работы с большими бинарными файлами и наиболее эффективен для относительно небольших текстовых данных. Программа также чувствительна к обрывам соединений в процессе передачи данных, при обрыве сессии уже загруженные данные потребует повторной загрузки. Кроме того, использование Git требует значительного дополнительного дискового пространства, что связано с необходимость хранения Git-репозитория на каждой клиентской системе, содержащего копию всех синхронизированных данных и историю их изменений. При этом, со временем, по мере накопления изменений, репозиторий может разрастись до значительных размеров, особенно если осуществляется работа с большими бинарными данными (например, при изменении бинарного файла в репозитории целиком будут сохранены прошлая и нынешняя версии файла).
Для обхода проблем с хранением бинарных данных, в конфигурациях связанных с хранением медиаконтента, предлагается (https://github.com/hbons/SparkleShare/wiki/Using-repositorie...) использовать git-fs (https://github.com/g2p/git-fs) для монтирования удалённого репозитория без создание локальной копии (в такой конфигурации репозиторий монтируется только в режиме чтения, что накладывает существенные ограничения на его использование). Другим путём оптимизации работы с бинарными файлами, который планируется интегрировать в SparkleShare 2.0, является использование проекта git-bin (https://github.com/Mighty-M/git-bin), в котором Git-репозиторий содержит только метаданные, а содержимое файлов разбивается на небольшие блоки, которые размещаются в отдельном хранилище.Из возможностей программы можно отметить средства для организации совместного доступа к файлам и обмена файлами с другими людьми. В том числе предусмотрен сервис (https://github.com/hbons/SparkleShare/wiki/Notification-service) отправки уведомлений между клиентами и возможность отправки инвайтов (https://github.com/hbons/SparkleShare/wiki/Invites) для автоматизации подключения к новым репозиториям. Для защиты информации, сохраняемой в публичных Git-репозиториях, может быть использовано шифрование (AES-256-CBC), применяемое на стороне клиента, перед отправкой данных на хост. Для расширения штатных возможностей программы предусмотрена система плагинов.
Управление и контроль за выполнением операций производится через графический интерфейс. Наборы обрабатываемых данных ассоциируются с определённой директорией в домашнем каталоге пользователя, содержимое которой автоматически синхронизируются с внешними Git-хранилищами и другими клиентами, для которых открыт доступ. При изменении файла участником группы, для других пользователей группы выводится всплывающее уведомление. В случае одновременного изменения одного и того же файла несколькими людьми запускается процесс разрешения конфликтов (создаются две копии).
URL: http://bomahy.nl/wordpress/?p=171
Новость: http://www.opennet.dev/opennews/art.shtml?num=35556
с этими, вашими, новыми, обоями, ничего не видать
Ну что их всех на гит тянет так в контексте, где у гита преимуществ вообще никаких? И при этом "графический интерфейс" вместо модулей к fuse...
Никаких преимуществ для дизайнеров у распределённых VCS? Батенька, да Вы шутник.Этот проект создан одним из дизайнеров MeeGo, а сейчас активно используется дизайнерами гнома для быстрого обмена набросками интерфейсов, значков и прочего (https://github.com/gnome-design-team).
Этак скоро выяснится, что дизайнерам не нужна ни отвязанность от одного рабочего места, ни децентрализованность, ни возможность хранения версий с визуальным их сравнением.
> Этак скоро выяснится, что дизайнерам не нужна ни отвязанность от одного рабочего места, ни децентрализованность, ни возможность хранения версий с визуальным их сравнением.А что, git уже научился визуально диффать графические файлы? Или архивировать блобы и их диффы? Или хотя бы докачивать файлы после разрыва?
> А что, git уже научился визуально диффать графические файлы?Это делает SparkleShare
А докачивать файлы Пушкин будет?
а сразу почему нельзя было скачать?
Да не делает оно ни хрена. Авторы что-то там думают, но сделать пока ничего не сумели. И не в диффах дело, а в том, что там нормлаьной архитектуры и близко нет.
батенька не шутник, батенька реалист. Бока не будет нормального дифа бинарников, это для жратвы не пригодно.
> батенька не шутник, батенька реалист. Бока не будет нормального дифа бинарников, это
> для жратвы не пригодно.Вам их в hex диффать хочется?
можно делать дифф бинарный, xdelta посмотрите.
Нет. Надо учить клиента понимать разные форматы и подходящим образом показывать различия. Для картинки - в рамочке различия показать, понимать несколько базовых трансформаций (ну там - кроп/масштабирование/поворот), и тому подобное. Тоолько это не дизайнеры писать должны, а нерды, дружащие с image recognition. Ну или если на это забить - то надо делать развитую систему тегов или категорий, в которой можнобудет нормлаьно описывать, что сделано в очередной версии, и по этому потом искать. Понятное дело - опять-таки с пониманием форматов - чтобы из jpg EXIF вытащило и тому подобное.
Ну вот заметно, что дизайнером писано. Впрочем, если б это написали в новости - вопросов бол бы меньше. ну ладно, локальная тулза написанная на том, что под рукой было. Потому что по уму гит - категорически неподходящий инструмент для таких случаев - собственно, проблемы упомянуты - большой объем локальных репозиториев (и удалённого тоже!), и проблемы с обрывами. При этом 90% функционала git здесь непригодно, так как расчитано на тектсовые данные. А специфики бинарей нет никакой.То, что вы перечислили - понятно, что вещи часто нужные, но для бинарей специализированное что-то надо. В идеале - понимающее распространенные форматы файлов и учитывающее их особенности, но как минимум - предусматривающее вменяемый менеджмент версий и несколько более широкие возможности хранения метаинформации, чем гит.
А вообще - судя по моему опыту дизайнерам, юристам и подобным товарищам децентрализованные версионники противопоказаны - на локальной машине у них слишком часто происходят инциденты вида "случайно удалил" и "не знаю, куда положил". Как минимум - кроме всего прочего сохраненная версия должна уходить куда-то в централизованное хранилище, где его случайно прибить без особых полномочий не получится и где за сохранность информации отвечает квалифицированный админ. SVN здесь себя отлично показывает, для него это совсем родной workflow. С гитом - можно, но надо вешать хуки, которые на коммит сразу пушили бы в свою веткуна сервере, и прикрывать всякие push --force.
Действительно, не допираю. Редкий случай где от fuse мог бы быть толк дабы вместо имения дел с очередными потугами в гуятине цепануть в любимом файлманагере и не парить мозг. Так нет, фиг вам.
Gnome... C#? Странно, ведь в Gnome есть замена до-диезу: Vala (https://wiki.gnome.org/Projects/Vala) называется. И работает быстрее, и синтаксис такой же, как у сишарпа. Ну, и git для бинарников непригоден.
