В свое время активно использовал на работе cvs, для контроля изменений на сайте.
На следующей работе использовал perforce и clearcase. На другой работе использовал subversion, затем mercurial, в уме держу git. Надеюсь понятно, что взгляд на системы контроля версий вполне широкий. Да и с утилитами diff, patch очень хорошо знаком.
Во первых, всегда удивляет, что пытаются сравнивать обе системы с svn, cvs, clearcase, но не между собой, когда только между собой их и можно сравнивать. С другими системами просто идеологически нельзя сравнивать. Все остальные не являются распределенными и не зависимыми от сервера. Разве что в плане функциональности сравнивать, где слияние удобнее или еще какие фишки (например, файл конфигурации в clearcase).
Как только вы теряете контакт с сервером вы никто, даже зафиксировать свои изменения не сможете, но в Mercurial и Git можете. И это главное преимущество этих двух систем Mercurial и Git перед всеми остальными.
Пока вы сидите в офисе друг напротив друга, сервачок жужит где-то рядом, все отлично работает в subversion или clearcase, слияние и ответвление, красивые графики в trac, что откуда и куда влилось и вылилось (не без напильника конечно).
Но все это идеально работает до вашей первой командировки в составе команды, когда вечером всей команде срочно требуется править код, так сказать в зависимости от суровых реалий. Когда нет не то что связи с центральным сервером, но даже некогда разбираться с wifi и bluetooth между ноутбуками, а самое верное средство обмена по прежнему флешка.
Причем subversion очень любит запоминать ip адрес сервера и даже простое вливание дампа репозитория сервера на новое место(ноутбук) не поможет, пока не зальете исходники с нового сервера(который встал на ноутбук). В результате, только какой нить merge по локальным файлам и помогает. А по приезду обратно, все начинают мучительно вливать килотонны своих изменений в subversion попутно вспоминая, что же за неделю было сделано и зачем.
Вот после пары, тройки таких командировок стал интересоваться Mercurial, но использовать стал много позже.
Во вторых, Mercurial на момент нашего интереса был более развит под windows, чем Git, сейчас у Git с этим тоже уже нет проблем. Но хочется отметить отличия. Mercurial в основном написан на Python с мелкими вкраплениями на C. В отличие от Git, который целиком написан на с и имеет много зависимостей с архитектурой linux, иначе бы не отвязывали так долго. Соответственно установить mercurial на хостинге с существующим python проще. Но Git в хороших традициях linux/unix состоит из набора консольных программ, чтобы их можно было легко использовать в скриптах на bash, tcl/tk. Соответственно, с Mercurial интереснее взаимодействовать через python, а с Git через обычный ввод/вывод.
В третьих, собственно интерес к Git был однажды снова подогрет после прочтения презентации про Git Линусом Торвальдсом и сравнения двух этих систем на code.google.com.
В качестве фишки, которой меня манил Git, был индекс похожести (similarity index). Дело все в том, что Git ведет не историю отдельных файлов, а сразу историю всех изменений в файловой системе в целом. Если вы переименуете один файл в другой, то Git это легко найдет, так как хэш sha1 двух файлов будет один и тот же, только изменится название файла. Это весьма важная вещь, знать откуда у тебя на самом деле взялся файл, особенно, если он был копией другого уже существующего файла (это конечно можно сделать административно :D).
Но как известно хотелось большего. Цитирую из презентации: "Одно из особенных свойств git — отслеживание изменений всего содержимого, и это отличает git даже от Mercurial, несмотря на то, что они очень похожи. "
В общем, в тайне надеялся, что в Git реализовано отслеживание перемещения кусков кода из одного файла в другой или их размножение путем копирования в рамках одного файла. То есть, увидеть, что какой-то кусок кода был взят из другого проекта, и потом немного исправлен. Я понимаю, несколько утопично, особенно если представить, что for копируется везде где только можно, с легкими изменениями в рамках одной строки :D.
Но увы моя мечта не сбылась, все что удалось добиться сейчас от Git, так это то, что Git может показать, что файл с такой-то вероятностью является копией другого файла, так как его после копирования изменили до неузнаваемости. Да и то для этого надо передать серию волшебных ключиков.
git diff --find-copies-harder --pickaxe-all --color HEAD~2 diff --git a/6.txt b/10.txt similarity index 80% copy from 6.txt copy to 10.txt index f8e89fb..cf9ebe7 100644 --- a/6.txt +++ b/10.txt @@ -1,3 +1,4 @@ +888 111 222 333 @@ -5,4 +6,3 @@ 555 666 777 -888 diff --git a/7.txt b/7.txt new file mode 100644 index 0000000..1bfd9c2 --- /dev/null +++ b/7.txt @@ -0,0 +1,5 @@ +111 +222 +333 +444 + diff --git a/8.txt b/8.txt new file mode 100644 index 0000000..92263e5 --- /dev/null +++ b/8.txt @@ -0,0 +1,5 @@ +444 +555 +666 +777 +888 diff --git a/6.txt b/9.txt similarity index 80% copy from 6.txt copy to 9.txt index f8e89fb..cf9ebe7 100644 --- a/6.txt +++ b/9.txt @@ -1,3 +1,4 @@ +888 111 222 333 @@ -5,4 +6,3 @@ 555 666 777 -888
Это максимум что удалось добиться. Кстати, чтобы git легко находил копии файлов рекомендуется на каждый чих делать фиксацию изменений, иначе копию можно изменить до не узнаваемости :D на момент фиксации.
Сейчас я считаю утопичным мое желание, так как оно мне в общем-то ничего не дает, и заодно сильно усложняет сам git, так как задача поиска одинаковых кусков кода по исходникам весьма не простая.
Во всяком случае видеть ее реализацию хотелось бы пожалуй уже немного в другой форме. Например, в утилите blame, когда по участку кода, можно было бы попросить найти, то место откуда код был взят, а не только кто автор. Чтобы проследить эволюцию кода. Также хотелось бы видеть эволюцию кода не только вниз но и вверх, может мою функцию кто нибудь у себя улучшил, а я не знаю, или наоборот в коде предке уже ошибку исправили, а я все еще пользуюсь старой копией ошибочного кода из другого проекта (по идее такоей код надо выделить в подпроекты).
В последних, хотелось бы обратить внимание на то, что Mercurial больше подходит для не больших проектов, к тому же он в самом деле проще в освоении, чем Git в котором только для того, чтобы научиться просмотреть изменения, мне понадобилось перечитать кучу документации и потратить уйму времени, не менее часа. Но Git предоставляет достаточно много опций и утилит облегчающих контроль большого проекта.
Например, способ с помощью которого легко найти проблемный commit, который испортил сборку всего проекта не проверяя каждый commit в отделььности, а лишь только сообщая какой из тысячи commit-ов после теста оказался проблемным или не проблемным. Не простая задача, и таких мелочей в Git много.
Например, возможность добавления в уже зафиксированное изменение забытых файлов, которые вы просто забыли добавить, не создавать же для этого в репозитории отдельное изменение.
Сообщения
