2009-07-22 3 views
4

Я смотрел презентацию YouTube Tech Talk: Linus Torvalds on git несколько недель назад, и одно замечание, похоже, застряло у меня в голове.Перенос возможностей слияния GIT на SVN?

В этой презентации (около минуты 33) Линус говорит что-то по строке «Некоторые люди клонируют репозиторий SVN, сливаются (= головная боль в SVN), а затем возвращают результат в SVN».

Мысль о том, что у меня есть: если это возможно, то почему мы не переносим большие возможности слияния GIT, чтобы стать неотъемлемой частью SVN?

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

Должно быть, я что-то пропустил. Что это?

+1

IIRC, Линус также говорит, что он всегда прав, и вы не должны его спрашивать :-) – balpha

+0

Я знаю. Я уже признал, что был глупым и уродливым;) –

ответ

7

Существует еще одна большая разница между SVN и GIT, кроме одного централизованного центра, а другая нет. GIT отслеживает содержимое, SVN отслеживает файлы.

Если вы объединяете ветвь в SVN, SVN вычисляет изменения, внесенные вами в ветку, и применяет их к соединительной линии (или независимо от вашей цели слияния). Эти модификации затем переносятся в репозиторий через обычную фиксацию, и исходная информация (история в ветке) забыта. В более поздних версиях SVN (> = 1.5) поведение слияния улучшилось, SVN теперь помнит, какие ревизии ветки были объединены, а какие нет, но базовая проблема все еще существует.

OTOH GIT расскажет вам с радостью в своем журнале, что некоторые строки вашего кода исходят из ветки xyz и что они модифицированы в ревизии a, b и c ветки. Это делает его очень простым для создания сумасшедшего слияния, например создания ветви, работы над ней, обновления до основной линии, выполнения еще одной работы, слияния в магистрали, отделения ветви и т. Д. Без каких-либо проблем.

UPDATE:

Итог: SVN и GIT только к разным в том, как они отслеживать изменения, SVN слияния может стать так круто, как в GIT, не становясь GIT.

1

Вы знаете, что improved merging capabilities в Subversion с 1.5? Это намного богаче, чем раньше. У меня не было проблемы с слиянием с момента перехода на 1.5. Мне было бы интересно узнать, какие функции GIT имеют в более поздних версиях Subversion.

+1

Из предоставленной ссылки я вижу, что: 1.) mergeinfo не отображается/используется по умолчанию в «svn log» и «svn wame», 2.) обрабатывает магистраль и ветку по-разному: опция '--reintegrate', 3.) не может иметь дело с criss-cross (циклическими) слияниями, 4.) имеет проблемы с переименованием файлов и каталогов. 5.) не svn: mergeinfo хранится на клиенте, а не на сервере (i-репозиторий)? –

0

Git и SVN - это два совершенно разных способа решения одной и той же проблемы, один из которых распределен по центру, поэтому вы не можете просто подключить код GIT к SVN. Это было бы похоже на попытку интеграции JQuery с устаревшим приложением VB6.

+2

Я знаю, что обе системы построены вокруг совершенно разных концепций. Моя мысль заключается в том, что одно из важных преимуществ GIT представляется переносимым в SVN. –

+0

См. Самый высокий голосовой ответ для более подробной версии моего ответа. – Jared

2

Обратите внимание, что упомянутый Google Talk о Git (BTW, вы можете прочитать стенограмму в Git Wiki: LinusTalk200705Transcript), состоялся до Subversion 1.5. В то время Subversion просто не хранил, необходимый для интеллектуального слияния Git-like отслеживание слияния информация (если вы не использовали расширение svnmerge или SVK, который является (полу) распределенным SCM поверх Subversion).

0

С 2009 года там было по крайней мере одна инициатива «исправить» СВН слияния:

См «It's Time to Fix Subversion Merge», июль 2011 (хотя большинство комментариев принуждая идти с Git;))
И см страница проекта «Subversion NewMerge merge fix», которая включает в себя изменение how merge is tracked.
Однако этот проект, похоже, пока не выпускает никакого релиза.

Смежные вопросы