CVS vs SVN

Mon, 12 Sep 2005 17:43:53 +0400 Alex Mogilnikov wrote to Harry Zhurov:

AM> 12 Sep 05 15:36, Harry Zhurov писал Andy Mozzhevilov:

HZ>> Hе только. Hе только отсутствие необходимости руками метить, но и HZ>> атомарность коммита, когда коммитится проект целиком, а не отдельные HZ>> файлы. Т.е. начал ты коммитить в cvs, тут - бац, какие-то файлы HZ>> обломались - конфликт по ним вышел. Что получается? Получается, что HZ>> часть файлов из новой версии, а часть от старой, и состояние проекта в HZ>> репозитории какое-то непонятное.

AM> Как ты умудрился такого добиться? cvs не выполняет commit, если есть AM> конфликт хотя бы по одному из файлов.

Уже не помню. Когда такое случилось, был очень огорчен.

Tue, 13 Sep 2005 07:51:51 +0400 Andy Mozzhevilov wrote to Harry Zhurov:

AM> 12 Sep 05 15:36, Harry Zhurov wrote to Andy Mozzhevilov:

AM>>> То есть сделали из SVN - CVS , пpичем добавив pепозитоpиев :)

HZ>> Hе понял, на что ты намекаешь. Да, в svn может быть сколько угодно HZ>> репозиториев и лежать они могут где угодно.

AM> Только лишь то, что с моей точки зpения, и для меня опять же, все новые AM> навоpоты svn это пpимеpно то же, что кyпить сотовый телефон с видеокамеpой, AM> fm-pадио и каpтой памяти, отдавая дань моде. А сами эти фyнкции мне нафиг AM> не нyжны.

Никакой дани моде нет! Просто ты используешь систему контроля версий очень ограниченно (хотя и глубоко). У тебя она только для контроля за сорцами и все. Причем все сорцы из всех проектов, насколько я помню, свалены в одну иерархическую кучу. Т.е. тут ты используешь cvs так, что скорее не ты ее под себя заточил, а она тебя под себя. Как только ты выйдешь за эти рамки, столкнешься с ее "прелестями" по полной программе. У меня, в частности, в проект входят и всякие файлы с настройками проекта редактора, workspace'ы оболочки симулятора, куча служебных файлов, документация и даже сопутствующие утилиты. И далеко не все они текстовые. Вот так проект и живет - и всегда можно вытащить его состояние не только в плане исходников, но и всего его окружения.

Т.ч. насчет моды - это ты напрасно, совершенно неадекватная аналогия.

HZ>>>> использующие эту ось, то апдейт будет осуществляться через HZ>>>> репозиторий.

AM>>> Все то же, что и в CVS. Hе лyчше.

И не хуже.

HZ>> Так тебе ж cvs нравится. Так что тебя не устраивает? Ты хотел таскание HZ>> общей части - оно реализуется, таскай сколько хочешь в скольки хочешь HZ>> проектах, что тебе не нравится?

AM> Пока это не совсем очевидно. Пока я не yвидел, что кто-то так делает, а AM> лишь некотyю теоpию, что так можно. У SP есть некотоpые сомнения по поводy AM> yдобности этих опеpаций. См. его письмо с описанием пpоекта в modules CVS, AM> и отсyтствии этого в SVN. Также yпоминание пpо некий switch.

Спорить бесполезно. Если тебе svn неинтересна, давай закончим эту дискуссию. Если интересна, то почитай доку, как говорит SP (чтобы не упоминать выражения "некий switch").

AM>>> Сопpовождение бинаpников? Мне лично не сильно то и надо, пpи том что в AM>>> большинстве слyчаев сpавнение бинаpников не имеет особого смысла.

HZ>> Это потому, что до сих пор у тебя проекты под контролем только HZ>> сорцовые. А вот положи под контроль версий что-то иное, сразу разницу HZ>> поймешь. Вот документацию в вордовых файлах ты под контролем не держишь? А HZ>> почему?

AM> А какой смысл бинаpные doc файлы там деpжать, если их изменения сpедствами AM> SVN все pавно пpосмотpеть не yдается.

Потому, что удобно. При коммите пишешь комментарий, при логе сразу видно, сколько ревизий файла и что про них сказано. Что касается сравнения, то можно вызывать внешнюю прогу для этого. Для сорцов я так и делаю (Compare It! использую). Это куда как удобнее, оперативнее и безопаснее ихнего встроенного diff'а.

Tue, 13 Sep 2005 13:02:40 +0400 Alex Mogilnikov wrote to Harry Zhurov:

AM> 13 Sep 05 13:57, Alex Mogilnikov писал Harry Zhurov:

AM>> А разве у cvs diff встроенный? Я всегда считал, что вызывается AM>> внешний...

AM> Сейчас глянул в исходники - действительно, встроенный. Тем более теперь AM> хотелось бы узнать, чем он небезопасен.

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

Tue, 13 Sep 2005 17:56:57 +0400 Alex Mogilnikov wrote to Harry Zhurov:

AM>>> Сейчас глянул в исходники - действительно, встроенный. Тем AM>>> более теперь хотелось бы узнать, чем он небезопасен.

HZ>> Тем, что выдает инфу в неудобоваримом виде, где легко проглядеть HZ>> нужное.

AM> Уф-ф-ф (вытирая холодный под со лба). Ты так больше не пугай. :) Это AM> не безопасность, а удобство.

Кому как. Если инструментарий позволяет допускать ошибки пусть путем крайне неудобного способа предоставления данных, это не делает его безопасным.

HZ>> Глаз замыливает, легко сделать ошибку. Hи в какое сравнение не HZ>> идет в случае с гуиными прогами, где сравнивание производится в двух HZ>> панелях с выравниванием и цветовым выделением.

AM> Честно говоря, ничего лучше я пока не видел. Порекомендуй, что AM> посмотреть. Только желательно консольное, а не графическое.

Что значит "консольное"? Выводящие на консоль или запускаемое из консоли? Или чтобы сама прога была консольная? Я такую знаю одну (мне Редчук как-то давно уже кидел ее) - tfc называется. Но у нее есть ограничение на ширину - 80 символов. В итоге гуйные и тут лучше. Я пользуюсь "Compare It!", есть аналогичная в составе SlickEdit'а, Diffzilla называется. Все они предоставляют интерфейс в виде двух панелей, где сравниваемое выравнивается, чтобы одинаковые куски были строго напротив (пустые места, если они есть, маркируются цветом). Различия метятся разным цветом. Более того, если в соответствующих строках есть просто отличающиеся символы, они тоже маркируются разным цветом, т.ч. сразу все видно. Очень удобно и _безопасно_ - пропустить, не увидеть что-то можно только если этого хотеть. Кроме того, "Compare It!", в частности, умеет не только сравнивать, но и редактировать - можно прямо тут же из одного окна в другое скопировать вариант, который нужен.

Что касается консоль (как таковая) vs. GUI, то я тоже предпочитаю консоль, где это разумно и удобно. Например, все файловые операции у меня в FAR'е. Но комппарилку файлов я предпочел гуйную, т.к. она лучше той консольной. И вызываю ее из FAR'а, сравнивая файлы в панелях оного.

AM> Кстати, diff умеет выводить на две панели. Только это неудобно.

Именно! Результаты сравнения несравненно лучше выглядят в графическом виде и любовь к консоли этого не компенсирует. То же самое относится и ко многим САПРам - ты же схемы/платы в гуином Пикаде лабаешь, а не в консольной проге в псевдографике. Потому, что тут оно по сути, принципиально лучше. И сравнивалка, хоть и не в такой мере, как Пикад, но тоже рулит в гуином исполнении.