Рассмотрим этот простой код python, который демонстрирует очень простой вариант управления версиями для диктатора:
def build_current(history):
current = {}
for action, key, value in history:
assert action in ('set', 'del')
if action == 'set':
current[key] = value
elif action == 'del':
del current[key]
return current
history = []
history.append(('set', '1', 'one'))
history.append(('set', '2', 'two'))
history.append(('set', '3', 'three'))
print build_current(history)
history.append(('del', '2', None))
history.append(('set', '1', 'uno'))
history.append(('set', '4', 'four'))
print build_current(history)
for action, key, value in history:
if key == '2':
print '(%s, %s, %s)' % (action, key, value)
Обратите внимание, что с помощью списка истории вы можете восстановить текущий словарь в любом состоянии, которое оно когда-то существовало. Я считаю это "форвардной сборкой" (из-за отсутствия лучшего термина), потому что для создания текущего словаря нужно начинать с самого начала и обрабатывать весь список истории. Я считаю это наиболее очевидным и прямым способом.
Как я уже слышал, ранние системы управления версиями использовали этот процесс "прямой сборки", но они не были оптимальными, поскольку большинство пользователей больше заботятся о последних версиях сборки. Кроме того, пользователи не хотят загружать всю историю, когда они только заботятся о том, чтобы увидеть последнюю сборку.
Тогда мой вопрос, какие существуют другие подходы для хранения историй в системе управления версиями? Возможно, можно использовать "обратную сборку"? Это может позволить пользователям загружать только последние версии, не требуя всей истории. Я также видел несколько разных форматов для хранения истории, а именно: изменения, моментальные снимки и патчи. Каковы различия между наборами изменений, моментальными снимками и патчами?
Из современных популярных доступных элементов управления версиями, как они хранят свои истории и каковы преимущества их различных конструкций?
