Как заставить Subversion (или любую программу) выполнять периодические коммиты?

Question

Я хочу настроить свой компьютер так, чтобы каждые полчаса он автоматически фиксировал программу, над которой я работаю. Я использую svn-репозиторий, поэтому даже если бы это был просто скрипт, который запускал 'svn ci' каждые 30 минут, это было бы нормально. Проблема в том, что я не знаю, как это сделать.

Может кто-нибудь сказать мне, или направить меня к чему-то, что позволило бы мне заставить работать этот периодический коммит?

Заранее спасибо.

РЕДАКТИРОВАТЬ: Извините, похоже, что я запутал людей, почему я хотел бы сделать это. Единственная причина, по которой я хочу это сделать, заключается в том, что мой лектор хочет, чтобы мы знали, как развивается наш код с течением времени, и я подумал, что было бы хорошей идеей использовать svn для этой цели. Неважно, работает последний коммит или нет. Он просто должен показать изменения, которые я внес в код с течением времени.

Answer 1

Вопреки очевидному распространенному мнению, я думаю, что это хорошее применение svn в контексте задания.

Такие инструменты, как kdesvn (или даже лучше, tortoisesvn, но это только для окон), могут дать вам отличное представление о том, что происходит, с их представлениями журнала, различиями и визуальными эффектами.

Если вы используете Ubuntu, запустите этот скрипт bash из консоли, отдельной от той, над которой вы работаете.

#!/bin/bash
while [ 1 ]
do
        # Do the commit
        svn ci --message "Automated commit" ~/yourworkingcopy

        # Wait until next commit time
        sleep 1800
done

Answer 2

Вы можете попробовать задание cron, которое запускает скрипт оболочки. На какой ОС вы работаете?

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

Answer 3

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

Тогда я предлагаю следующее: используйте репозиторий для вашего программного обеспечения и еще один для хранения автофиксаций. Когда работа завершена, объедините все автоматические коммиты в главном репозитории только в один логический коммит.

С git я бы сделал это:

1. Репо 'foo': основной репозиторий
   1. ссылки / головы / ...: расположение ваших веток разработки
   2. refs / session / ...: расположение вашей работы с грязными коммитами.
2. Ваша рабочая копия:
   1. "git init"
   2. "git remote add foo git: // foo / ...; git fetch foo"
3. создать ветку: "git checkout -b bar foo / master"
4. отметьте начало ветки: "git tag barbegin"
5. активировать скрипт: "while true; сделать git add -A.; Git commit -m 'autocommit'; done"
6. Я бы не использовал задание cron, поэтому вы можете легко активировать / деактивировать автокоммиты.
7. делай свою работу
8. после завершения работы отключите скрипт
9. зафиксировать ожидающие изменения
10. теперь у вас есть много автоматических коммитов на панели веток, и вы пометили начальный коммит ветви с помощью barbegin
11. опубликуйте ваши автоматические коммиты:
    1. "git tag barend"
    2. "git push foo barbegin: refs / session / ваш идентификатор пользователя / идентификатор сессии / begin"
    3. "git push foo barend: refs / session / ваш идентификатор пользователя / идентификатор сессии / end"
12. теперь вы опубликовали свою работу, и ваш лектор может получить к ней доступ
13. для обновления вашего репозитория foo:
    1. "git rebase -i --onto barbegin barbegin" и действуйте, как описано здесь
    2. Я бы раздавил все коммиты: "в конце концов, может быть только один".
    3. "git push foo bar: master" # будет выдвинут только один коммит
14. уборка:
    1. "git tag -d barbegin"
    2. "git tag -d barend"
    3. "git branch -d bar"

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

Answer 4

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

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

Абсолютно возможно со всеми разновидностями make, и я знаю, что Visual Studio имеет события до и после сборки, которые можно настроить для выполнения чего-то подобного. Поэтому я уверен, что большинство современных IDE справятся с этим.

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

Answer 5

Вы можете попробовать этот рецепт: http://code.activestate.com/recipes/577570-watch-directory-and-do-periodic-commits-to-subvers/

Answer 6

Я бы использовал Subversion, но вместо этого я привык бы работать над отдельными изменениями и вносить их в репозиторий.

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

Answer 7

Если вы работаете в среде UNIX, рассмотрите возможность создания задания cron для регулярного запуска команд.