Непрерывный контроль версий
Я не видел систему непрерывного контроля версий - такую, которая бы сохраняла изменения в вашем коде по мере их разработки, а не ожидала официальной регистрации. Изменения будут сохранены как "не проверенные", конечно, но они будут быть сохранены для резервного копирования и просмотра другими, прежде чем вы действительно сделали официальную регистрацию.
Я не видел этого и удивляюсь, существует ли это или что-то подобное, и причины, по которым это может или не может быть хорошей идеей.
Прямо сейчас программисты думают об управлении исходным кодом как об интеграции пакетов кода, но почему бы не сделать эти пакеты меньше и интегрировать непрерывно?
-Адам
16 ответов
Прямо сейчас программисты думают об управлении исходным кодом как об интеграции пакетов кода, но почему бы не сделать эти пакеты меньше и интегрировать непрерывно?
Я бы сказал, что DVCS уже в основном делают это сейчас, не потому, что они децентрализованы, а потому, что коммиты выполняются намного быстрее. С git я фиксирую гораздо чаще, чем с SVN. Это также упрощает фиксацию "чанков" или определенных кода (используя git add -i или же git gui), и, как правило, гораздо больше внимания уделяется отслеживанию строк кода, а не целым файлам (как "традиционные" VCS, такие как Subversion)
Кроме того, то, как по сути работает git, означает, что, как вы сказали, "изменения будут сохранены как" не проверенные ", конечно". Когда вы фиксируете изменения, они локальные, затем вы отправляете их на удаленный компьютер с отдельной команда.. Вы можете зафиксировать каждый раз, когда вы сохраняете, а затем преобразовать их в один коммит, если хотите.
Что касается инструмента, который выполняет "непрерывный контроль версий", вы можете сделать это довольно просто с помощью сценария оболочки, что-то вроде..
while [ 1 ]; do
git add -a && git commit -m "Autocommit at $(date)";
sleep 10;
done
Есть скрипт CACM ( github), который делает что-то похожее
[CACM] наблюдает за конкретным каталогом и фиксирует все изменения в автономном репозитории Git.
Чтобы использовать просто сделать:
cacm --repo dir_of_git_repo --watch dir_to_watch
Я не уверен, почему вы захотите это сделать. Я считаю, что одна из самых полезных вещей в использовании VCS - это разница в том, что я изменил (со времени последнего коммита). Кажется, что постоянные / автоматические коммиты были бы просто шумом.
Кроме того, текстовый редактор "e" имеет интересную особенность, он визуализирует историю отмены с ветвлением. На нем есть пост в блоге со скриншотами.
Работа по постоянному автосохранению - задача не для системы версий, а для редактора. Когда вы видите новую версию в системе версий, она должна представлять собой значимое изменение по сравнению с другими версиями, а не каждое наполовину набранное слово.
Eclipse имеет функцию под названием "локальная история", которая делает именно это. Он сохранит копию ваших исходных файлов между сохранениями. Он даже отслеживает удаленные папки для вас. Это спасло мой приклад несколько раз. Вы можете видеть Local History как низкоуровневое управление версиями, которое происходит только на вашем локальном компьютере. Недостатком этого является, конечно, когда вы работаете на другой машине, у вас будет другая местная история.
Я видел несколько плагинов на основе inotify для различных DVCS, однако они могут быть только умными. Действительно, идеальное решение - хранить репозиторий в файловой системе с копированием при записи, чтобы эти частые гранулярные (и неизменяемые) версии файлов оставались за пределами DVCS.
Как уже говорили другие, я предпочитаю брать на себя множество небольших обязательств. С DVCS вам не нужно беспокоиться о том, чтобы сломать магистраль или основную ветвь, нажмите только после того, как вы закончите... не беспокойтесь о ядовитых ревизиях при редактировании файлов.
В Linux я использую ext3cow для хранения своих репозиториев HG/Git. Это дает мне ту функциональность, которую вы описываете. К сожалению, я не знаю ничего подобного, которое могло бы переноситься за пределы Linux. Может быть, какая-нибудь сумасшедшая команда придумает такую в Python.
Этот вопрос уже несколько раз поднимался (хотя каждый в отдельном контексте), поэтому, безусловно, необходимость чего-то вроде ext3cow (но переносимого) очевидна. Тем не менее, я не хотел бы, чтобы это раздуло в самой DVCS, особенно на огромных деревьях.
Я думаю, что вам действительно нужно запрашивать это из файловой системы, а не из DVCS.
Ты имеешь в виду что-то вроде аверверсии Subversion?
Отказ от ответственности: я не говорю, что автоверсия это хорошая идея для разработки или что я бы лично это сделал, но технология существует.
Вы не хотите проверять каждое изменение. Вы хотите проверить атомарные наборы изменений, которые могут работать вместе. Вы не хотите добавлять параметр в метод и сохранять его, зарегистрировав его (и запустить сборку CI), а затем прервать сборку, потому что вы еще не обновили вызовы метода.
Вы можете зафиксировать каждую строку или символ с помощью DVCS, например, git, если хотите. Вообще, я думаю, что это хорошая идея - использовать как можно чаще при использовании DVCS, чтобы упростить поиск проблем с помощью таких инструментов, как git bisect. Если вы хотели, чтобы эффект, который вы описали, вы могли написать свой редактор для фиксации при каждом сохранении... На практике, хотя я думаю, что это будет немного.
Я думаю, что Eclipse делает, или делал что-то подобное при каждом сохранении. Это спасло меня несколько раз, когда мой код в итоге был взломан на части при попытке идентифицировать ошибку.
Здесь другой подход. Почти каждый день я сталкиваюсь с ситуациями, когда что-то перестает работать, и я не знаю почему. Я перематываю пару минут и проверяю, какие изменения были внесены и в какие файлы. Поэтому я согласен с необходимостью непрерывного контроля версий.
В то же время верно, что вы не хотите вносить тысячи мелких изменений каждый день в свой репозиторий.
Итак, это то, что вы делаете. Вы используете оба, но не смешиваете их. Ваш источник контроля должен использоваться всей командой, и вы время от времени проверяете это. В то же время вы запускаете локальное программное обеспечение для создания личных версий файлов, которое сохраняет каждое небольшое изменение и позволяет вам на самом деле использовать информацию.
Вот и все. Я использую History Explorer, так как помогал в его разработке, но есть и другие.
Некоторые люди настраивают ветку разработки для этой цели и заставляют разработчиков вносить изменения во время работы, прежде чем объединять их с веткой уровня обеспечения качества. Вы могли бы даже сделать так, чтобы разработчик работал над основными изменениями в своей собственной ветке, прежде чем фиксировать и объединять эти изменения с основной веткой разработки. Таким образом, ветвление может решить эту проблему.
Возможно, вас заинтересует система непрерывного контроля версий, разработанная JetBrains. Это еще не общедоступно, но я показываю некоторые особенности этого в своем выступлении на JetBrainsDay в Мальме: http://new.livestream.com/jetbrains/jetbrainsday1/videos/29348962
Имея более чем многолетний опыт программирования на Java, я до сих пор помню (с ностальгией) новый подход, который Visual Age привнес в процесс разработки. В Visual Age был нефайловый подход к исходному коду. Код был сохранен в реляционной базе данных. Как правило, вы работаете над представлением, показывающим один метод. У вас также был полный просмотр файла, но вы бы не стали его так часто использовать.
Что касается контроля версий, он будет генерировать версию при каждом сохранении. Вы можете явно проверить контрольную точку для метода, класса / интерфейса, пакета или всего проекта с номером / именем версии. Это также позволило более детально контролировать ваш источник на уровне метода. Как только я начал работать с Eclipse, хотя он унаследовал многие функции от Visual Age, и сегодня у него есть функция History, которая локально сохраняет все "сохранения" вашего кода, я не мог не чувствовать, что сделал шаг назад.
Rational ClearCase имеет концепцию динамического просмотра. В Windows ваш вид разработки отображается как подключенный диск, но изменения кода сохраняются на стороне сервера, как только вы нажмете "Сохранить". Это то, что вы ищете?
Как и следовало ожидать, с такой работой приходится идти на компромиссы, так что, как и в ответе si618 выше, это не рекомендация...
Как упоминал Дэн, в IBM Visual Age IDE сохранялась каждая сохраненная вами версия файла исходного кода. Однако этот подход не ограничивается IDE; операционная система DEC VMS использовала аналогичный подход с версионной файловой системой. В VMS полное имя каждого файла включало номер версии, и каждый раз, когда вы сохраняли файл, создавалась новая копия с номером версии на один больше, чем предыдущее наибольшее число.
Ни один из этих подходов не совсем соответствует контролю версий, как мы его знаем сегодня, в том смысле, что у обоих отсутствует ветвление (или, в этом отношении, любые функции, разработанные специально для облегчения работы нескольких человек над одним и тем же исходным файлом). Но оба они служат для резервного копирования от человеческих ошибок, что для меня является наиболее полезным аспектом контроля версий.