Re[2]: Подход git
От: elw00d Россия http://elwood.su
Дата: 16.12.11 14:31
Оценка:
Здравствуйте, netch80, Вы писали:

N>Здравствуйте, elw00d, Вы писали:


E>>Посмотрел известное выступление Торвальдса в гугле по поводу git, практически все понятно, но одна деталь не дает мне покоя. Торвальдс говорит ближе к концу о том, что git, в отличие от других систем контроля версий, отслеживает историю проекта "целиком", а не пофайлово. Мне интересно — Торвальдс считает это именно особенностью DCVS-подхода в сравнении с SVN либо же git как-то совсем по-другому манипулирует версионируемым контентом, даже не так, как это делает меркуриал ? Если первый вариант и Линус этим предложением сравнивает git и svn, то все понятно — git манипулирует деревом коммитов, а svn — деревом файлов.


N>Нет. SVN тоже не работает как таковое с деревом файлов, это не CVS. SVN сходно с git методами работы с контентом — действия определяются сразу по группе объектов, обычно иерархически собранных, как файлы.

N>Отличие тут только то, что формально на нижнем уровне git это не файлы, а просто как-то именованные объекты (строками, завершёнными нулевым символом), и на нижнем уровне можно с ними работать не как с файлами. Но, на моей памяти, никто так с этими объектами не работает. Хотя, может, я не знаю про какие-то особенности. Для юзера, работающего с файловым деревом, это всё пофиг.

N>Более того, рассказы, например, что в git единицей хранения является порция содержания, неверны. Например, перемещение файла — это удаление одной копии и создание другой, а логическое оформление действия как перемещение производится уже уровнем выше (когда ищется similarity index и если он 100%, то это просто перемещение).


E>> Однако если вариант второй, то в чем же может быть различие в подходе между git и mercurial ? По-моему, между ними различия в основном непринципиальные (типа что у гита нет named branches, а у меркуриала нельзя сливать за раз больше 2 ветвей).

E>>В общем, хотелось бы уточнить, что Линус имеет в виду, и как его система трекает историю функций между файлами (ведь из контекста выступления кажется, что только гит это умеет делать — вопрос — можно ли сделать аналогичную функциональность скажем в mercurial, или это невозможно в силу дизайна).

N>git может следить историю между файлами, но, как уже сказал, делает это хреново. Чтобы найти факт перемещения функции, например, надо дойти до коммита, где эта функция перешла в другой файл и перезапустить чтение истории уже для этого файла. Это возможно, но как минимум на уровне CLI неудобно. Может, какой-то GUI есть, что это следит, я не видел.


Что-то я совсем теперь запутался. Насчет SVN и git мне кажется, что все верно — хоть вы и написали, что SVN работает не как CVS. Вы имели в виду то, что коммит атомарен в svn как и в git ? Но git идет дальше и в его истории мы видим дерево коммитов (ациклический граф, точнее), а в svn — только прямую историю. И ветки svn всегда идут "параллельно" (потому что merge на самом деле не merge, а получение диффа и потом его применение на текущей ветке). Поэтому Линус говорит о том, что "контент" проекта виден в git целиком, а в svn мы видим только историю текущей ветки с непонятными вкраплениями патчей из других веток. Поправьте, если я неправильно понимаю.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.