Использование git для отслеживания изменений в Dropbox?

Перейти к нижней части для TL;DR.

Вопрос:

В нашей среде каждый использует Dropbox для совместной разработки большого проекта кодирования. Это решает проблему того, чтобы все были в курсе того, что изменили все остальные, и также предоставляет некоторые простые версии для "кто изменил что и когда".

Что Dropbox не предоставляет, и это то, что я ищу, - это Git удивительный соус, в отношении версий, вины, различий контента и т.д.

То, с чем я сейчас работаю:

Я все еще использую dropbox как наш "контроль версий", потому что другие "разработчики", вероятно, не смогут понять git, я знаю, что это легко, но они ненавидят изменения.

Чтобы я увидел, "что действительно происходит, и кто это делает", я отслеживаю всю папку Dropbox для этого проекта, используя Git.

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

То, что я ищу:

Есть ли у кого-нибудь опыт работы с окружающей средой, в которой я застрял? Я хотел бы найти что-то, что может заметить изменение в Dropbox, вытащить имя пользователя, кто сделал это изменение, используя API Dropbox и автоматически зафиксировать изменение на Git.

Я не нашел такого решения и уже начал писать приложение на Python, чтобы делать то, что хочу, мне, возможно, придется разместить это на github и попросить о помощи, с низким свободным временем и относительно новым для Python.

Я могу вытащить RSS-канал из API Dropbox и проанализировать, что такое файл и кто его изменил, но я недостаточно далеко, чтобы подключить его к Git Commit, должен быть тривиальным. Я просто не хочу изобретать все колеса.

TL;DR:

Я хотел бы автоматически отслеживать изменения, которые происходят в Dropbox и имейте их Git Committed, включая имя человека который изменил файл в Dropbox, используя API Dropbox или аналогичный. Вероятно, используя Python, но все приветствуется.

Спасибо заранее.

Git Repo, если вы хотите помочь! https://github.com/haqthat/git-drop

Ответ 1

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

Ответ 2

Если вы можете разместить его на linux, как насчет использования iwatch? Всякий раз, когда файл обновляется в папке Dropbox с помощью синхронизации Dropbox, iwatch может запускать python script, когда это происходит, чтобы вытащить пользователя. Затем используйте envoy для запуска двух команд git, git add 'filename' и git commit -m "autocommit by system for user X changes".

Конечно, это не очень красиво, но он выполнит задание, и он не будет работать, если не будет обновления.

Ответ 3

Я использовал dropbox как репозиторий git, следуя чему-то в строках http://tumblr.intranation.com/post/766290743/using-dropbox-git-repository

Таким образом, самый простой способ, о котором я могу думать, это:

1) Инициировать репо в папке с Dropbox (это позволит автоматически синхронизировать всех, с которыми вы делитесь)

2) Настроить его с помощью пульта дистанционного управления на github или вашего собственного сервера git, если таковой имеется. Таким образом, все изменения файлов и пользователей будут отслеживаться на пульте дистанционного управления.

3) Напишите script как задание cron, которое периодически берется из вашего локального Dropbox и затем запускается против удаленного git сервера и ищет дельта и ревизии. Вы можете получить это от Dropbox API ref, начиная с этого момента - https://www.dropbox.com/developers/reference/api#revisions

4) После выполнения выше вы можете включить вызов https://www.dropbox.com/developers/reference/api#metadata, который, как и в dropbox, возвращает хэш, который может быть используется для отслеживания изменений, а затем вызывает ваш опрос script. На данный момент не существует способа, по которому dropbox может уведомить вас об изменениях, отличных от вашего опроса, каждые несколько минут на пульте дистанционного управления.

hash Each call to /metadata on a folder will return a hash field, generated by hashing all of the metadata contained in that response. On later calls to /metadata, you should provide that value via this parameter so that if nothing has changed, the response will be a 304 (Not Modified) status code instead of the full, potentially very large, folder listing. This parameter is ignored if the specified path is associated with a file or if list=false. A folder shared between two users will have the same hash for each user.