![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kikaОбнаружил оппортюнитю. В мире, оказывается, нету нормальной широко распространенной build system/SCM. Замечательные в своей непостижимости autotools просто непригодны ни на чем кроме юникса, не менее замечательный CMake просто халтурно сделан - у него отличная идея и где-то примерно на треть хороший дизайн, а две трети дизайна и реализация просто мусор. qmake пригоден для использования только в коммерческой версии Qt и кроме того весьма ограничен в возможностях.
Я сильно подозреваю что купив за десять тыщ мильенов фунтов долларов какой-нибудь перфорс я получу такую же помойку, только еще и без исходников.
Либо это никому не надо, либо до сих пор никто не нагнулся и не поднял с земли деньги.
Compliance test для любой билдовой системы: напишите "makefile" в ней, который позволит собрать из одних исходников в один проход статическую и динамическую библиотеку под линукс. А отдельный проход под виндами соберет статическую и динамическую библиотеку под венды. Если тест пройден, сделайте тоже самое, но со сборкой промежуточной convenience library.
Мы в результате остановились на CMake + autotools для того, на что CMake просто непригоден.
Я сильно подозреваю что купив за десять тыщ мильенов фунтов долларов какой-нибудь перфорс я получу такую же помойку, только еще и без исходников.
Либо это никому не надо, либо до сих пор никто не нагнулся и не поднял с земли деньги.
Compliance test для любой билдовой системы: напишите "makefile" в ней, который позволит собрать из одних исходников в один проход статическую и динамическую библиотеку под линукс. А отдельный проход под виндами соберет статическую и динамическую библиотеку под венды. Если тест пройден, сделайте тоже самое, но со сборкой промежуточной convenience library.
Мы в результате остановились на CMake + autotools для того, на что CMake просто непригоден.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Re: p4
Date: 2006-12-15 03:22 pm (UTC)Re: p4
Date: 2006-12-15 03:30 pm (UTC)Re: p4
Date: 2006-12-15 04:30 pm (UTC)Основные плюсы - стабилен, быстр, интегрируется со всем, поддерживает branching, atomic commits.
Re: p4
Date: 2006-12-15 05:01 pm (UTC)Re: p4
Date: 2006-12-15 05:14 pm (UTC)- нормальных меток (а не копий дерева)
- changeset'ов как отдельных объектов, с которыми можно делать всякие полезные штуки. Например, выгрузить changeset в виде списка файлов и diff'а, разложить файлы, которые уже модифицированны в рабочей копии по нескольким changeset'ам прежде, чем субмитить их в репозиторий и т.п.
У P4 есть свои недостатки в сравнении с SVN'ом. Например:
- переименование файлов и директорий теряет старую history (вернее, ее можно посмотреть по старому имени объекта, но жизнь нового начинается с момента переименования). В SVN'е этого не происходит
- P4 хранит метаданные для рабочей копии неизвестно где, а SVN - в директориях .svn прямо в рабочей копии. В результате, у P4 рабочую копию не переместишь просто так на другое место
- каждая рабочая копия регистрируется у P4 на сервере. В результате, если у меня 2 компутера, я вынужден держать 2 аккаунта. Кроме очевидных неудобств, надо еще понимать, что деньги P4 берет именно per-account.
- svn diff очень быстрая команда, т.к. сравнивает локальные файлы на диске. У перфорса и CVS'а эта команда требует слазить на сервер
- P4 не очень хорош для offline'овой работы, когда файл сначала поменяешь, а потом когда-нибудь выложишь, когда доберешься до интернета
- виндовая гуйня (TortoiseSVN) у SVN'а по-моему дружелюбнее, чем то страшилище, которое прилагается к P4
Может быть, кто-нибудь возбудится, и доделает к SVN'у недостающую функциональность? :-)
Re: p4
Date: 2006-12-15 06:02 pm (UTC)Re: p4
Date: 2006-12-15 06:41 pm (UTC)Метки я-ля перфорс это именованные объекты (кажется даже версионированные), состоящие из комментария и списка пар {имя файла; версия}. Такую штуку можно добавить в SVN, даже не модифицируя сервера, если договориться, что метки хранятся в виде файлов в определенном (желательно текстовом) формате и в определенном месте.
Мне бы лично хватило бы и более простой конструкции, а именно метка содержащая не список файлов, а ссылку на директорию (с указанием версии), ко всем файлам которой она рекурсивно относится.
По сравнению с перфорсовскими ченжсетами в SVN'е не хватает следующего:
- в SVN'е нет команды, позволяющей получить список файлов, которые поменялись в релизе N (в SVN'е, как и в P4 релиз это чиселка, характеризующая версию репозитория в целом, а не конкретного файла). Но есть команда, позволяющая получить diff между версиями N и M (в частности, между N-1 и N - почти то, что нужно). Поскольку diff имплицитно :-) содержит список файлов, осталось только отломить тело diff'а, чтобы сделать эту команду немного побыстрее. Это потребует изменения на стороне сервера.
- svc ci пытается засубмитеть все измененные файлы, которые он нашел, от текущей директории и дальше по дереву. Как и в CVS'е, тебя отправляют поредактировать текстовый файл, в котором сверку можно написать log, а снизу - список измененных файлов. P4 делает практически то же самое, но только я могу еще поредактировать список файлов - удалить из него файлы, и это будет означать, что они не будут засубмиченны в этот раз. Это удобно, когда делаешь сразу несколько изменений в проекте, но оформить их хочется отдельными субмитами.
- P4 позволяет поредактировать log и список файлов, но в репозиторий пока ничего не сохранять, а отложить на попозже. При этом создается объект по фамилии changeset, который по существу представляет не что иное, как текстовый файл с log message и списком файлов. Хранится он, правда, на сервере, и тем самым виден другим пользователям, но по-моему, его с таким же успехом можно было бы хранить локально и другим пользователям не показывать.
- diff между версиями N-1 и N можно получить из P4 в точно таком же формате, в котором создаются changeset'ы. Это делает changeset не write-only объектом. Кстати, поредактировать можно только еще не засубмиченный changeset, что вполне логично.
Я не думаю, что это сложно реализовать. Почти все запчасти в SVN'е для этого уже есть...
Re: p4
Date: 2006-12-15 06:17 pm (UTC)Все лучше люди здесь у Кирилла собрались ;-)
С p4 живу последние четыре года. Очень даже удачная штука. Но с SVN сравнить не могу, ибо не знаком.
Как build-систему его использовать никак нельзя. Как ее часть, ответственную за извлечение требуемого из репозитория - очень даже можно (так и делаем).
С аккаунтами по-моему ты что-то не так делаешь. Один P4USER может существовать на произвольном количестве компьютеров и иметь произвольное количество P4CLIENTs.По крайней мере до сих пор мы в ограничения вписываемся без проблем (полсотни юзеров с несколькими клиентами каждый).
Недостаток, серьезнейший, p4 для офлайновой работы по-хорошему не приспособлен абсолютно.
Графический клиент - очень на любителя. Юниксовый - так вообще на мазохиста-любителя. command-line удобный.
Re: p4
Date: 2006-12-15 07:21 pm (UTC)Я примерно понимаю, что Кириллу не нравится в Jam'е. Jam это по сути make, а Кириллу хочется тулзу, которая для его любимой Visual Studio генерит проекты.
Кстати, на Jam'е сидит PalmOne. Я в свое время всласть натрахался с их билдовой системой, когда мне понадобилось что-то собрать немного не так, как они привыкли.
С аккаунтами - да, немного напутал. Я уже забыл, что P4USER != P4CLIENT. Но необходимость иметь несколько клиентов меня лично напрягала. Мне больше нравится ad hoc способ создания клиента в стиле CVS/SVN.
Что до гуйни, меня в этом вопросе можно смело не слушать, т.к. я гуйней почти не пользуюсь. Но все же P4'я гуйня по-моему крайний пример неудобства :-)
Очень удачной штукой P4 я назвать не могу. По-моему, это очередной "CVS better that CVS". P4, наверное, лучший из тех, кого я видел в этом классе. На вскидку не хватает:
- в P4 нет нормального rename. В CVS'е тоже нет. Более-менее есть только в SVN'е
- Многие команды в P4 и CVS'е лазают на сервер без нужды, и от этого работают слишком медленно (и вообще не работают без интернета)
- за время, которое CVS'у надо, чтобы поставить метку на исходники линуксного ядра, можно успеть пообедать. У SVN'а с этим хорошо. Про P4 не помню.
- Branch system в CVS'е, конечно, brain damaged, но в P4/SVN'е нету и такой :-(
- Никто из них не умеет при merge изменений из бранча A в бранч B учитывать, какие изменения были уже раньше помержены
- Мне бы очень хотелось иметь иерархию репозиториев, чтобы я мог, скажем, работать некоторое время в своем локальном репозитории, а проталкивать изменения в общий репозиторий лишь когда изменения достаточно созрели. Меня бы на худой конец устроил бы и приватный бранч, если бы не см. выше. Но локальный репозиторий лучше - с ним можно работать в оффлайне.
- Никто из них не поддерживает концепцию shared files а ля VSS. Эта штука очень полезна, чтобы шарить сишные хидеры между несколькими проектами.
- Никто из них не поддерживает легкого способа перенести приект из одного репозитория в другой (хорошо бы еще чтобы другой системы) с сохранением всей истории.
- Никто из них не позволяет легко получить версию того кода, который у меня лежит в рабочей копии в виде, пригодном для вставления в сишную программу - чтобы потом можно было написать эту чиселку в лог, и сопоставить лог с версией исходников. У P4 есть что-то подобное, но ему надо слазить на сервер, что вносит раздражающую задержку в процесс сборки программы. В CVS'е такого в принципе не может быть, т.к. у каждого файла своя версия. Про SVN не помню, но меня тоже что-то не устроило :-)
- Опечатку в log message совершенно невозможно исправить
- Ошибочный submit нельзя просто удалить
- Если файл случайно ушел не с тем changeset'ом, эту ошибку исправить нельзя. К CVS'у это не относится за неимением changeset'ов
Re: p4
Date: 2006-12-15 07:51 pm (UTC)- опечатку в log message исправить таки-можно в p4.
- насчет merge изменений - по-моему тоже не совсем точно. В этом плане p4 - лучшее, что я трогал. Он помнит историю предыдущих merge по p4 integrate и помнит ее достаточно хорошо. Можно даже mergить на уровне отдельного changelistа, опустив часть промежуточной истории. Что опять-таки удобно.
Относительно идеологии и возможности ad hocов, для разработчика, конечно, не очень удобно, но для построения build-системы - самое то.
Re: p4
Date: 2006-12-15 09:03 pm (UTC)Я имею ввиду следующее. У меня есть 2 параллельные ветки. Скажем, current и stable. Изменения вносятся в обе, причем часто независимо. Время от времени надо перенести изменения (часто кучкой) из одной ветки в другую.
Я хочу, чтобы source control понимал, какие изменения уже перенесены, а какие нет.
Насколько я понимаю, P4 так не умеет. А умеет он вместо того следующее: перенести изменения из ветки A в ветку B от версии 1.0 до версии 1.2, и запомнить, что B теперь уже отбранчена от 1.2, а не от 1.0, как было раньше.
Я не прав?
P.S. Вот Git, насколько я понимаю из его описания, делает это именно таким методом, как я описал. Насколько я понимаю его устройство, в Git'е по большому счету вообще нет такого объекта как файл. А первичным является именно изменение. Файл как таковой - это не более чем точка в истории файла (последовательность изменений, которая довела файл из небытия до такой жизни). Поэтому именно в плане работы с изменениями Git очень гибок.
Но это все мои домыслы - я его сам не щупал, только пару статей про него прочитал :-)
Re: p4
Date: 2006-12-18 08:43 am (UTC)Тут, что называется, show me the code:
http://www.finnov.net/~ank/p4.txt
Проще, чем описывать словами.
Коротко, если я во время интеграции что-то подправил руками, или изменения были сделаны в отдельной ветке, то в следующий раз они для интеграции предлагаться не будут. Что удобно.
Интеграцию отдельного changelist показывать не стал, но там все очень похоже.
Re: p4
Date: 2006-12-15 07:01 pm (UTC)- про переименования согласен
- перемещение в другое место настраивается через workspace
- насчет account'ов ты неправ. Можно под одним акаунтом иметь бесконечное количество воркспэйсов. Чем, когда лицензий не хватает, можно злоупотреблять.
- насчет diff'a не совсем понял. Если за время моего работы над файлом в репозитории появилась новая версия, как именно сравнение локальных файлов может помочь?
- оба гуя suck. Tortoise интегрируется с explorer'ом, что делает его совсем бесполезным для тех, кто им не пользуется в качестве файлменеджера.
Re: p4
Date: 2006-12-15 07:28 pm (UTC)Я бы пошел еще дальше, и хранил бы несколько, если не все версии локально. Место на моем диске стоит дешевле, чем мое время, в конце концов (для бедных и жадных можно сделать какую-нибудь настройку, сколько именно локальных копий хранится).
Перемещение в другое место через workspace, если не ошибаюсь, настраивается только через полный checkout проекта в новое место. Я работал в проекте, в котором полных чекаут занимал сутки. С точки зрения такого проекта в перфорсе нет возможности переместить файлы в другое место.
Про аккаунты мне уже объяснили.
Все гуи suck, но в виндовсе и консоль sucks, да еще и с причмокиванием - приходится пользоваться гуем хотя бы иногда :-)
Re: p4
Date: 2006-12-15 08:05 pm (UTC)По поводу перемешения, step by step instructions сейчас не дам, но я точно делал через модификацие workspace. По тем же причинам - из-за проблем с сетью full checkout was not an option.
Re: p4
Date: 2006-12-15 06:33 pm (UTC)Re: p4
Date: 2006-12-15 07:05 pm (UTC)Re: p4
Date: 2006-12-15 07:34 pm (UTC)Я работал год в проекте с репозиторием в SVN'е. За это время он не сломался не разу. Т.е., доступ к серверу иногда пропадал на некоторое время (видимо, до перезагрузки системы), но нарушений информации не разу не случалось.
SVN, правда, был не свой, а вот этот вот: http://cvsdude.com/
Кстати, SVN научился вроде уже держать свой репозиторий не только в Berkley DB, так что есть шанс, что эта проблема уже починилась. Если это единственное, чем не устраивает SVN, я бы посмотрел на свежие версии прежде чем платить бешенные бабки за P4.
Re: p4
Date: 2006-12-15 08:15 pm (UTC)Оно правда у нас хостится "в гараже".
Меня, как девелопера, SVN вобщем устраивает (если не падает ;-). Только changelists не хватает по большому счету.
Re: p4
Date: 2006-12-15 09:05 pm (UTC)Re: p4
Date: 2006-12-16 04:11 am (UTC)Re: p4
Date: 2006-12-16 01:05 pm (UTC)Re: p4
Date: 2006-12-16 06:42 pm (UTC)Re: p4
Date: 2006-12-16 06:57 pm (UTC)Во-первых, украв код, будет довольно сложно использовать его легальным образом. И более того, после того, как ты украл код, тебе будет трудно доказать, что твой собственный код имеет легальное происхождение. А вовлечено в это будет довольно много людей, так что утаить такой факт тоже будет непросто.
Во-вторых, физически код все равно не защитишь. Ты ведь не можешь быть абсолютно уверен в каждом, кто у тебя работает, не так ли?
Я бы больше опасался того, что грохнется вот в CVSdude винчестер, и окажется, что бакапы они не так хорошо умеют делать, как следовало бы. Но на такой случай за умеренную дополнительную денежку у них можно купить доступ к регулярным dump'ам, которые делаются с твоего репозитория.
Re: p4
From:Re: p4
From:Re: p4
From:Re: p4
From:Re: p4
From:Re: p4
From:Re: p4
Date: 2006-12-15 07:30 pm (UTC)