Рассмотрим этот простой код 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)
Примечание что, используя список истории, вы можете восстановить текущий словарь в любом состоянии, в котором он когда-то существовал. Я считаю это «прямой сборкой» (из-за отсутствия лучшего термина), потому что для создания текущего словаря нужно начинать с начала и обрабатывать весь список истории. Считаю это наиболее очевидным и прямым подходом.
Как я слышал, ранние системы управления версиями использовали этот процесс «прямой сборки», но он не был оптимальным, потому что большинство пользователей больше заботятся о последних версиях сборки. Кроме того, пользователи не хотят загружать всю историю, если их интересует только последняя сборка.
Мой вопрос: какие еще существуют подходы для хранения историй в системе контроля версий? Возможно, можно было бы использовать «обратную сборку»? Это может позволить пользователям загружать только последние версии без необходимости во всей истории. Я также видел несколько различных форматов для хранения истории, а именно: наборы изменений, моментальные снимки и исправления. В чем разница между наборами изменений, снимками и исправлениями?
Из доступных современных популярных элементов управления версиями, как они хранят свою историю и каковы преимущества их различных конструкций?