Как сделать Подверсию (или какая-либо программа) выполняют периодические фиксации?
Для этого потребуется изменить атрибут href и использовать тег данных (он же data:post.url). Новый код будет выглядеть как -
<a expr:href='"whatsapp://send?text=" + data:post.url' data-action="share/whatsapp/share">Share in Whatsapp</a>
6 ответов
Я бы не испортил вашу систему управления версиями такой серией автоматических коммитов. Но я согласен с идеей использования системы контрольной версии для предоставления этой информации.
Затем я предлагаю следующее: используйте репозиторий для вашего программного обеспечения и еще один для хранения автофиксаций. Когда работа будет завершена, объедините все автоматические коммиты в главном репозитории только с одним логическим коммитом.
С помощью git я сделал бы следующее:
- Repo 'foo': основной репозиторий
- ссылки / головы / ...: расположение ваших веток разработки
- ссылки / сессии / ...: местоположение вашей работы с грязными коммитами.
- Ваша рабочая копия:
- "git init"
- "git remote add foo git: // foo / ...; git fetch foo"
- создайте ветку: тег "git checkout -b bar foo / master"
- начало ветки: "git tag barbegin"
- активируйте скрипт: "while true; сделайте git add -A.; git commit -m 'autocommit'; done"
- Я бы не использовал задание cron, так что вы можете легко активировать / деактивировать автокоммиты.
- сделайте свою работу
- после того, как ваша работа будет выполнена, деактивируйте скрипт
- , фиксируйте ожидающие изменения
- сейчас, у вас есть много автоматических коммитов на панели веток, и Вы отметили начальный коммит ветки с помощью barbegin
- опубликуйте свои авто коммиты:
- "git tag barend"
- "git push foo barbegin: refs / session / ваш идентификатор пользователя / идентификатор сессии / begin"
- "git push foo barend: refs / session / ваш идентификатор пользователя / сессия id / end "
- Теперь вы опубликовали свою работу, и ваш лектор может получить к ней доступ
- для обновления вашего хранилища foo:
- чистка:
- «git tag -d barbegin»
- «git tag -d barend»
- «git branch -d bar»
После всего этого, я думаю, что полезная информация не может быть собрана с такими данными , Итак, я бы попытался избежать этого рабочего процесса. Но если бы это действительно было необходимо, я бы поступил так.
Вопреки очевидному распространенному мнению, я думаю, что это отличное использование 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
Вы можете попробовать задание cron, которое запускает скрипт оболочки. На какой ОС вы работаете?
Но мне любопытно, почему вы хотите это сделать. Ваши коммиты должны состоять из частей функциональности или исправления ошибок, а не на основе временного интервала. Скорее всего, вы совершите фиксацию в середине изменения (в группе файлов), что сделает ваши ревизии бесполезными.
Я не думаю, что установка коммитов по расписанию является особенно хорошей идеей. Особенно, если вы начинаете заниматься тестированием и непрерывной интеграцией. Фиксация с установленными интервалами будет нарушать сборку, потому что нет никакой гарантии, что вы завершите набор изменений за определенный период времени.
Лучший способ, если вы хотите выполнить автоматическую фиксацию, это сделать коммит частью самого процесса сборки. , Просто сделайте последний шаг процесса сборки коммитом в репозиторий. Таким образом, если сборка завершится неудачно, вы не будете фиксировать мусор.
Вполне возможно, со всеми разновидностями make, и я знаю, что Visual Studio имеет события до и после сборки, которые можно настроить для выполнения чего-то подобного. Поэтому я вполне уверен, что большинство современных IDE могут справиться с этим.
В качестве особого рассмотрения этой проблемы, в частности:
Переместите зацепку фиксации в начало процесса, чтобы вы могли отслеживать, когда вы по-королевски все перепутали и как вы пришли, чтобы исправить ошибки.
Я бы использовал Subversion, но вместо этого я бы просто привык работать над отдельными изменениями и заставлял их хранилище.
Таким образом, лектор, если он хочет, может посмотреть не только , что изменилось, но , почему он изменился. Это было бы гораздо полезнее, я бы вообразил.
Если вы работаете с версией UNIX, подумайте о создании задания cron для запуска команд на регулярный интервал.