среда, октября 17, 2007

Пост Comparing the Microsoft and Google tool chains

Некто Джэк Палевич (Jack Palevich) перешел работать из Микрософта в Гугл. И сравнивает теперь тулзы, которые он использовал в Микрософте с тулзами, которые используются в Гуле: Comparing the Microsoft and Google tool chains. И там, и там все фигово с системами контроля версий. Интересно, что Гугл гораздо щедрее в том, что касается закупки харда для разработчиков.

13 коммент.:

CyberZX комментирует...

странно, что МС не юзает VSS.

Анонимный комментирует...

> странно, что МС не юзает VSS.

Ничего странного. VSS совсем не предназначен для таких нагрузок, с какими легко справляется Source Depot.

Анонимный комментирует...

А что плохого в Perforce?

Unknown комментирует...

А что плохого в Perforce?
Народ жалуется на неудобство слияний (merges).

Анонимный комментирует...

Слияний? Странно. Вполне вменяемый механизм - трехстороннее слияние (общая базовая версия, две независимо измененные). Очень симпатичный стандартный модуль для слияния текстовых файлов, для бинарников можно запустить внешнюю программу. Автоматическое слияение есть, вполне удачное. Разумеется, конфликты редактирования надо разрешать вручную.
Не могли бы вы привести пример системы, в которой удобнее сливать изменения, чем в Perforce? Я хочу попробовать.

Когда я внедрял Perforce у себя, меня подкупило следующее: им могут пользоваться совершенно дубовые юзеры. При этом все возможности для программистов реализованы замечательно. Таким образом, в одной структуре можно держать, например, проектную документацию (дофига бинарных файлов в различных форматах) и исходные тексты.

На момент внедрения у меня это была единственная система, в которой без танца с бубном поддерживалась вся метаинформация (имена файлов, комментарии) на русском языке.

Alex Ott комментирует...

странно, что микрософт жадничает на железо - оно же сейчас стоит меньше чем месячная зарплата того-же программиста. Ну и IDE у гугла не ограничивается Eclipse - это видимо программист сам подбирал по похожести - ходили и скриншоты емакса и vim'а используемые в гугле

Alena комментирует...

А что плохого в Perforce?

В нем плохо все. Perforce ужасен.
Совсем недавно меня поставил в тупик один из пунктов меню "Revert if unchanged". Я думаю, он поставит в тупик любого, кто когда-либо пользовался системами контроля версий.
Дело в том, что в Perforce свой особый смысл имеют операции Check out и Revert. Как в том анекдоте, где было свое понятие логарифма.
Ситуацию усугубляют чудесные сообщения об ошибках вроде "can't clobber writable file".
Можно, конечно, поспорить, что при желании можно с ним разобраться и нормально работать (к Perforce'у прилагаются огромные гнетущие мануалы). Но я не хочу с ним разбираться, у меня есть более интересные и важные дела. С SVN мне разбираться не приходилось, например. Оно само работало так, как ожидалось.

в одной структуре можно держать, например, проектную документацию (дофига бинарных файлов в различных форматах) и исходные тексты.

Это могут многие системы контроля версий. SVN точно может.

На момент внедрения у меня это была единственная система, в которой без танца с бубном поддерживалась вся метаинформация (имена файлов, комментарии) на русском языке.

С комментариями у меня никогда проблем не возникало, русские имена файлов как-то не были нужны никогда...

Анонимный комментирует...

Да, есть в Perforce такая проблема - они изначально ввели нестандартную терминологию. Вмето "Check Out" у них было "Open for Edit" или просто "edit" если с командной строки, а вместо "Check In" - "Submit". Revert всегда было - откатить изменения.
Вообще-то терминология Perforce мне кажется более удобной - для пользователя перепутать "Check In" и "Check Out" значительно проще, чем "Edit" и "Submit".
В последних версиях P4V они перешли на стандартную терминологию, и это сразу вызвало проблемы у моих пользователей.

"Can't globber writable file" - это очень информативное сообщение о ошибке. Perforce обнаружил, что для одного из файлов, которые вы пытаетесь синхронизировать с сервера, в файловой системе клиента снят признак read-only. Это значит, что пользователь изменял файл не открывая его на редактирование. Чтобы вы не потеряли ваши изменения, Perforce отказывается их затирать до тех пор, пока вы сами, пользуясь средствами операционной системы, не поставите обратно признак read-only или совсем файл не сотрете. В мануале элементарно находится контекстным поиском. Так как таких сообщений может быть миллион, сообщение сделано максимально лаконичным.

Мануалы по Perforce - просто замечательные. Они действительно большие, но не от сложности, а от подробности. Отдельно раздел для админа и пользователя. Я пересилил себя и сначала прочитал мануал, после чего затруднений практически не было.

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

К Perforce можно предьявить технические претензии - один выделенный сервер без автоматического зеркалирования.
Можно финансовые - небесплатный. Для коммерческого использования - весьма небесплатный.
Можно принципиальные: код сервера - закрытый.

Касательно SVN - если бы оно было доступно в 2002 году, когда я разворачивал в организации Perforce (первый лист изменений датирован июлем 2002), может быть, я бы его и выбрал. Исключительно из экономии.

Анонимный комментирует...

Google осталось только выпустить свой web-браузер :)

Unknown комментирует...

Не могли бы вы привести пример системы, в которой удобнее сливать изменения, чем в Perforce? Я хочу попробовать.
Любую из распределённых систем контроля версий (Git, Darcs, Monotone) или хотя бы уже упомянутая Subversion, которая в сочетании с TortoiseSVN, обеспечивает нужную вам простоту в использовании.

Arseny Kapoulkine комментирует...

Про Perforce - я пользуюсь им уже пол года. По сравнению с tortoise svn - неудобная просматривалка дифов. Кошмарная мержилка - во-первых, автоматически мержит хуже того же svn, во-вторых при возникновении конфликта лично мне гораздо быстрее сохранить то, что оно намержило (формат тот же, что и у svn) и в нормальном текстовом редакторе смержить руками.

Ограничение в дифалке на 2 Mb. Может у нас версия старая?.. Если нет, то это идиотизм какой-то.

Ну и open for edit в общем напрягает, конечно. Даже вынесенный в visual studio соответствующий shortcut не совсем спасает - скажем, студия имеет обыкновение пытаться сохранять файл (бывает у меня раз в день) vcproj, не делая при этом в нем изменений.

Unknown комментирует...

Несколько лет пользовался Perforce, впечатления в целом приятные. Стандартным диффом и мержем пользоваться почти не доводилось - у нас в проекте использовался сторонний. А что до "Open for Edit", то в 2006 г. мы уже пользовались "Check out".

Сейчас приходиться пользоваться ClearCase'ом и честно говоря он меня напрягает.

Анонимный комментирует...

2 Niraxoid,
кто-бы могу в 2007 подумать, что гугл это уже запланировал :-)