ГИТ против.Perforce — две системы контроля версий войдут… одна выйдет [закрыто]
https://stackoverflow.com/questions/222782
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Итак, я занимаюсь продажей GIT на работе.Первое, что мне нужно, — это убедить всех, что GIT лучше справляется с тем, к чему они уже привыкли.Сейчас мы используем Perforce.Кто-нибудь еще проходил подобную распродажу?Есть хорошие ссылки/советы?
Одним из больших преимуществ является то, что мы можем работать с ним отключенным от сети.Еще одна победа, по моему мнению, — это способ обработки добавлений/извлечений.Больше баллов приветствуется!Также у нас около 10-20 разработчиков.
Решение
Исходный код интерпретатора Perl 5 в настоящее время проходит через процесс преобразования из Perforce в git. Может быть, интересен импортер Сэма Вилайна git-p4raw .
В любом случае, один из главных выигрышей, который вы будете иметь над всеми централизованными VCS, и большинство распределенных, также является «сырым», в результате чего скорость . Вы не можете себе представить, как это освобождает - иметь под рукой всю историю проекта, всего лишь доли доли секунды, пока вы ее не испытаете. Даже создание журнала фиксации всей истории проекта, которая включает в себя полный diff для каждого коммита, может быть измерено в долях секунды. Git так быстро, что ваша шляпа слетит. Системы VCS, которые вынуждены обходить сеть, просто не имеют возможности конкурировать, даже по каналу Gigabit Ethernet.
Кроме того, git позволяет очень легко быть осторожным при совершении коммитов, что позволяет распределять изменения в вашей рабочей копии (или даже в одном файле) по нескольким коммитам & # 8211; и в разных ветках, если вам это нужно. Это позволяет вам делать меньше мысленных заметок во время работы & # 8211; Вам не нужно так тщательно планировать свою работу, заранее решая, какой набор изменений вы совершите, и не откладывая что-либо еще. Вы можете просто вносить любые необходимые изменения, когда они происходят с вами, и все же распутывать их & # 8211; почти всегда довольно легко & # 8211; когда пора совершать. Шкатулка может быть очень полезной здесь.
Я обнаружил, что вместе эти факты заставляют меня делать гораздо больше и гораздо более целенаправленных коммитов, чем до того, как я использовал git. Это, в свою очередь, не только делает вашу историю в целом более полезной, но и особенно полезна для таких дополнительных инструментов, как git bisect .
Я уверен, что сейчас есть еще кое-что, о чем я не могу думать. Одна из проблем, связанных с предложением продавать свою команду на git, заключается в том, что многие преимущества взаимосвязаны и противоречат друг другу, как я намекал выше, так что трудно просто взглянуть на список возможностей и преимуществ git и сделать вывод, как они собираются изменить ваш рабочий процесс, и какие изменения будут добросовестными улучшениями. Вы должны принять это во внимание, и вам также нужно явно указать на это.
Другие советы
Я использую Perforce на работе. Я также использую Git, потому что мне все еще нужна какая-то форма контроля версий, когда я работаю над кодом и не могу подключиться к серверу. Нет, согласовать автономную работу просто не то же самое. Вот где я обнаружил, что git - большая выгода:
<Ол>Мне потребовалось бы много убедительных, чтобы переключиться с выступления. В двух компаниях, которые я использовал, это было более чем достаточно. Обе они были компаниями с разрозненными офисами, но офисы были созданы с большим количеством инфраструктуры, поэтому не было необходимости иметь разрозненные / отключенные функции.
Сколько разработчиков вы говорите о переходе?
На самом деле вопрос в том, что Git может обеспечить вашими потребностями, которые не отвечают потребностям вашей организации? И точно так же, какие недостатки у git по сравнению с производительностью? Если вы не можете ответить на этот вопрос самостоятельно, тогда вопрос здесь не поможет. Вам нужно найти экономическое обоснование для вашей компании. (например, возможно, это связано с более низкой общей стоимостью владения (которая включает потерю производительности на промежуточном этапе обучения, более высокие затраты на администрирование (по крайней мере, на начальном этапе) и т. д.)
Я думаю, что вас ждут жесткие продажи - производительность довольно хорошая, чтобы попытаться ее заменить. Это не просто, если вы пытаетесь загрузить pvcs или ssafe.
Я думаю, что с точки зрения того, чтобы люди были довольны во время / пост-переключения, одна из вещей, о которых нужно рано говорить, это то, насколько частным может быть локальное отделение в Git, и сколько свободы дает им делать ошибки. Заставьте их всех клонировать себе несколько частных веток из текущего кода, а затем безумно экспериментируйте. Переименуйте некоторые файлы, проверьте содержимое, объедините элементы из другой ветки, перемотайте историю, переместите один набор изменений поверх другого и так далее. Покажите, как даже их худшие происшествия на местах не имеют последствий для их коллег То, что вам нужно, - это ситуация, когда разработчики чувствуют себя в безопасности, чтобы они могли учиться быстрее (так как Git имеет крутую кривую обучения, что важно), а затем, в конечном итоге, чтобы они были более эффективными как разработчики.
Когда вы пытаетесь освоить централизованный инструмент, очевидно, вы будете беспокоиться о том, чтобы сделать какую-то глупость, которая создаст проблемы для других пользователей хранилища. Одного страха смущения достаточно, чтобы отговорить людей от экспериментов. Даже имея специальную «тренировку» Репозиторий не помогает, потому что разработчики неизбежно столкнутся с ситуацией в производственной системе, которую они никогда не видели во время обучения, и поэтому они снова начинают беспокоиться.
Но распределенная природа Git устраняет это. Вы можете попробовать любой эксперимент в локальной ветке, и если это пойдет не так, просто выбросьте ветку, и никто не должен знать. Поскольку вы можете создать локальную ветвь чего угодно, вы можете воспроизвести проблему, с которой вы столкнулись, в реальном живом хранилище, но при этом нет опасности "сломать сборку". или иначе выставить себя дураком. Вы можете проверить абсолютно все, как только вы это сделаете, не пытаясь пакетировать работу в аккуратные маленькие пакеты. Так что не только два основных изменения кода, которые вы потратили четыре часа сегодня, но и исправление сборки, которое вы запомнили на полпути, и орфографическая ошибка в документации, которую вы заметили, объясняя что-то коллеге, и так далее. И если основные изменения будут отменены, потому что проект меняет направление, вы можете выбрать исправление сборки и орфографическую ошибку из своей ветки и оставить их без проблем.
Команда, которая продала меня лично на git, была разрез`ать . Я не думаю, что эта функция доступна в любой другой системе контроля версий на данный момент.
При этом, если люди привыкли к клиенту с графическим интерфейсом для управления исходным кодом, они не будут впечатлены git. Прямо сейчас единственным полнофункциональным клиентом является командная строка.
Какие функции Perforce используют люди?
- Несколько рабочих пространств на одном компьютере
- Нумерованные списки изменений
- Ветви разработчика
- Интеграция с IDE (Visual Studio, Eclipse, SlickEdit, ...)
- Множество вариантов сборки
- Составные рабочие пространства
- Интеграция одних исправлений, но не других
- и т. Д.
Я спрашиваю, потому что, если все люди делают, это получают и помещают из командной строки, git это покрывает, как и все другие RTS.
Видимо GitHub теперь предлагает компаниям курсы обучения git.Цитата их сообщение в блоге об этом:
За последние несколько недель я несколько раз бывал в кампусе Google, помогая обучать там Android-смартфонов Git.Шон Пирс (возможно, вы знаете его по славе Git и EGit/JGit — он герой, который берет на себя обслуживание, когда Юнио нет в городе) попросил меня прийти и помочь ему обучить инженеров Google, работающих над Andriod, в переход с Perforce на Git, чтобы Android можно было распространить среди широких масс.Могу сказать вам, что я был более чем счастлив сделать это.
[…]
Logical Awesome теперь официально предлагая этот тип услуги индивидуального обучения для всех компаний, где мы можем помочь вашей организации с обучением и планированием, если вы также думаете о переходе на Git.
Акцент мой.
Я давно использую Perforce, а недавно я также начал использовать GIT. Вот моя "цель" мнение:
Выполните функции:
<Ол>GIT функции:
<Ол>В целом для OpenSource / Distributed проектов я бы всегда рекомендовал GIT, потому что это больше похоже на P2P-приложение и каждый может участвовать в разработке. Например, я помню, что когда я занимался удаленной разработкой с Perforce, я синхронизировал 4 ГБ проекты по каналу 1 Мбит / с один раз в неделю. Из-за этого было потрачено много времени. Также нам нужно было настроить VPN для этого.
Если у вас небольшая компания, а P4-сервер будет работать всегда, я бы сказал, что Perforce также является очень хорошим вариантом.
Некоторое время мы использовали Git, недавно произошел сбой жесткого диска нашего сервера Git, и мы не смогли вернуться к последнему состоянию. Нам удалось вернуться на несколько дней назад. Когда сервер был восстановлен. Каждый в команде вытащил / протолкнул свои изменения и вуаля, сервер вернулся в текущее состояние.
Одним из важных отличий между Perforce и git (и наиболее часто упоминаемым) является их соответствующая обработка больших двоичных файлов.
Как, например, в этом блоге сотрудника компании по разработке видеоигр: http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html
Тем не менее, важно то, что разница в скорости между git и performance, когда у вас огромный репозиторий 6 Гб, содержащий все, от документации до каждого когда-либо созданного двоичного файла (и, наконец, да, фактическая история исходного кода), обычно происходит из-за того, что огромные компании, как правило, запускают Perforce, и поэтому они настроили его так, чтобы перенести все важные операции в огромный серверный банк в подвале.
Это важное преимущество со стороны Perforce обусловлено только тем фактором, который не имеет ничего общего с Perforce, а именно тем фактом, что компания, в которой он работает, может позволить себе указанный банк серверов.
И, в любом случае, в конце концов, Perforce и git - это разные продукты. Git был разработан исключительно как VCS, и он делает это намного лучше, чем Perforce (в том смысле, что он имеет больше функций, которые, как правило, проще в использовании, в частности, в словах другого, ветвление в Perforce похоже на выполнение с открытым сердцем операция, это должны делать только эксперты: P) ( http://stevehanov.ca/ blog / index.php? id = 50 )
Любые другие преимущества, которые компании, использующие Perforce, получили, стали возможными только потому, что Perforce не только VCS, но и файловый сервер, а также множество других функций для тестирования производительности сборок и т. д.
И наконец: Git с открытым исходным кодом и гораздо более гибким в загрузке, не так уж и сложно исправить Git для выгрузки важных операций на центральный сервер, на котором работает огромное количество дорогого оборудования.
Я думаю, что единственное, что я знаю, побеждает GIT - это его способность "сохранять окончания строк". для всех файлов, в то время как Perforce, похоже, настаивает на переводе их в формат Unix, Dos / Windows или MacOS9 (" \ n " \ r \ n " или \ r).
Это настоящая боль, если вы пишете сценарии Unix в среде Windows или в смешанной среде ОС. Невозможно даже установить правило для каждого расширения файла. Например, он преобразует файлы .sh, .bash, .unix в формат Unix и преобразует файлы .ccp, .bat или .com в формат Dos / Windows.
В GIT (я не уверен, что это опция по умолчанию, опция или единственная опция), вы можете установить для нее значение «сохранить окончания строк». Это означает, что вы можете вручную изменить окончания строк в файле, и тогда GIT оставит этот формат таким, какой он есть. Мне кажется, это идеальный способ сделать что-то, и я не понимаю, почему это не вариант с Perforce.
Единственный способ добиться этого - пометить файлы как двоичные. Как я понимаю, это было бы отвратительно, чтобы обойти отсутствующую функцию. Помимо того, что надо утомительно выполнять все сценарии и т. Д., Он также, вероятно, нарушит большинство различий и т. Д.
«Решение» На данный момент мы решили выполнить команду sed для удаления всех возвратов каретки из сценариев каждый раз, когда они развертываются в их среде Unix. Это тоже не идеально, тем более что некоторые из них развернуты в файлах WAR, и строка sed должна быть запущена снова, когда они распакованы.
Это просто то, что, по моему мнению, дает GIT большое преимущество, и о котором я не думаю, что было упомянуто выше.
РЕДАКТИРОВАТЬ: после более длительного использования Perforce я хотел бы добавить еще пару комментариев:
A) Что-то, чего мне очень не хватает в Perforce, - это чистый и разный экземпляр, включающий измененные, удаленные и добавленные файлы. Это доступно в GIT с помощью команды git diff , но в Perforce файлы должны быть извлечены до того, как их изменения будут записаны, и хотя ваши основные редакторы (например, Eclipse) могут быть настроены на автоматическое проверять файлы при редактировании, иногда вы можете редактировать файлы другими способами (блокнот, команды unix и т. д.). И новые файлы, кажется, не добавляются автоматически вообще, даже с использованием Eclipse и p4eclipse, что может быть довольно раздражающим. Таким образом, чтобы найти все изменения, вы должны запустить " Diff против ... " во всем рабочем пространстве, которое, во-первых, требует времени для запуска, а во-вторых, включает в себя все виды неактуальных вещей, если только вы не создали очень сложные списки исключений, что приводит меня к следующему пункту.
B) В GIT я нахожу .gitignore очень простым и легким в управлении, чтении и понимании. Однако списки игнорирования / исключения рабочей области, настраиваемые в Perforce, кажутся громоздкими и излишне сложными. Я не смог получить никаких исключений с подстановочными знаками. Я хотел бы сделать что-то вроде
-//Server/mainline/.../target/... //Svend_Hansen_Server/.../target/...
Чтобы исключить все целевые папки во всех проектах внутри сервера / магистрали. Однако, похоже, это не работает так, как я ожидал, и я добавил строку для каждого проекта, например:
-//Server/mainline/projectA/target/... //Svend_Hansen_Server/projectA/target/...
-//Server/mainline/projectB/target/... //Svend_Hansen_Server/projectB/target/...
...
И аналогичные строки для папок bin, файлов .classpath и .projet и других.
C) В Perforce есть довольно полезные списки изменений. Тем не менее, предположим, что я делаю группу изменений, проверяю их все и помещаю их в список изменений, чтобы затем поработать над чем-то другим перед отправкой этого списка изменений. Если позже я внесу изменения в один из файлов, включенных в первый список изменений, этот файл все еще будет в этом списке изменений, и я не смогу позже отправить список изменений, предполагая, что он содержит только те изменения, которые я первоначально добавил (хотя будут те же файлы). В GIT, если вы добавите файл, и они внесут в него дальнейшие изменения, эти изменения не будут добавлены (и будут отображаться в git diff , и вы не сможете
У меня нет опыта работы с Git, но я имею дело с Mercurial, который также является распределенной VCS. На самом деле это зависит от проекта, но в нашем случае распределенная VCS подходит для проекта, поскольку в основном устраняет частые неработающие сборки.
Я думаю, что это действительно зависит от проекта, так как некоторые лучше подходят для клиент-серверных VCS, а другие - для распределенных.
Вот что мне не нравится в git:
Прежде всего, я думаю, что идея распределенного управления противоречит реальности.Все, кто на самом деле используют git, делают это централизованно, даже Линус Торвальдс.Если бы ядро управлялось распределенным образом, это означало бы, что я не мог бы загрузить «официальные» исходные коды ядра — их бы не было — мне пришлось бы решать, нужна ли мне версия Линуса или версия Джо. или версия Билла.Очевидно, это было бы смешно, и именно поэтому существует официальное определение, которым Линус управляет с помощью централизованного рабочего процесса.
Если вы признаете, что вам нужно централизованное определение ваших вещей, тогда становится ясно, что роли сервера и клиента совершенно разные, поэтому догма о том, что клиентское и серверное программное обеспечение должно быть одинаковым, становится чисто ограничивающим.Догма о том, что клиент и сервер данные должно быть одинаковым, становится явно нелепым, особенно в кодовой базе с пятнадцатилетней историей, которая никого не волнует, но всем придется клонировать.
Что мы на самом деле хотим сделать со всеми этими старыми вещами, так это засунуть их в шкаф и забыть о том, что они там есть, как это делает любая обычная система контроля версий.Тот факт, что git каждый день пересылает все это туда и обратно по сети, очень опасен, потому что вам приходится его сокращать.Такая обрезка требует принятия множества утомительных решений, и она может пойти не так.Таким образом, люди, вероятно, будут хранить целую серию репозиториев снимков из разных моментов истории, но разве не для этого изначально был предназначен контроль версий?Этой проблемы не существовало, пока кто-то не изобрел распределенную модель.
Git активно призывает людей переписывать историю, и, вероятно, вышеизложенное является одной из причин этого.Каждая нормальная система контроля версий делает невозможным перезапись истории для всех, кроме администраторов, и гарантирует, что у администраторов не будет причин рассматривать это.Поправьте меня, если я ошибаюсь, но, насколько я знаю, git не предоставляет возможности предоставить обычным пользователям доступ на запись, но запретить им перезаписывать историю.Это означает, что любой разработчик, у которого есть обида (или который все еще испытывает трудности с обучением), может уничтожить всю кодовую базу.Как нам это ужесточить?Ну либо вы делаете регулярное резервное копирование всей истории, т.е.вы сохраняете историю в квадрате или запрещаете доступ для записи всем, кроме какого-то бедняги, который будет получать все различия по электронной почте и объединять их вручную.
Давайте возьмем пример хорошо финансируемого крупного проекта и посмотрим, как у него работает git:Андроид.Однажды я решил поиграть с самой системой Android.Я узнал, что мне нужно было использовать кучу скриптов под названием repo, чтобы получить доступ к их git.Некоторые репозитории выполняются на клиенте, а некоторые — на сервере, но оба уже самим своим существованием иллюстрируют тот факт, что git несовершенен в любом качестве.Произошло следующее: я не мог вытащить исходники около недели, а потом вообще сдался.Мне пришлось бы вытащить действительно огромный объем данных из нескольких разных репозиториев, но сервер был полностью перегружен такими людьми, как я.Тайм-аут репо истек, и он не смог возобновить работу с того места, где он истек.Если бы git был настолько распространяемым, можно было бы подумать, что они сделали бы что-то вроде одноранговой сети, чтобы уменьшить нагрузку на этот сервер.Git распространяется, но это не сервер.Git+repo — это сервер, но репо нельзя распространять, потому что это просто специальный набор хаков.
Аналогичной иллюстрацией неадекватности git является gitolite (и его предшественник, который, очевидно, не сработал так хорошо). Gitolite описывает свою работу как упрощение развертывания git-сервера.Опять же, само существование этой штуки доказывает, что git не является сервером, равно как и клиентом.Более того, этого никогда не будет, потому что, если бы оно переросло в любую из них, это было бы предательством своих основополагающих принципов.
Даже если бы вы верили в распределенность, git все равно был бы беспорядком.Что такое, например, филиал?Говорят, что вы неявно создаете ветку каждый раз, когда клонируете репозиторий, но это не может быть тем же самым, что и ветка в одном репозитории.Итак, это как минимум две разные вещи, называемые ветвями.Но затем вы также можете перемотать репозиторий назад и просто начать редактирование.Это что-то вроде ветки второго типа или опять что-то другое?Возможно, это зависит от того, какой тип репо у вас есть - о да - видимо, репо тоже не очень четкое понятие.Есть нормальные и голые.Вы не можете перейти на обычный вариант, потому что голая часть может не синхронизироваться с исходным деревом.Но вы не можете выполнить cvsimport в голую версию, потому что они об этом не подумали.Таким образом, вам нужно cvsimport в обычный, клонировать его в голый, который используют разработчики, и cvsexport в рабочую копию cvs, которую еще нужно проверить в cvs.Кого это может беспокоить?Откуда взялись все эти сложности?Из самой распределенной идеи.В конце концов я отказался от гитолита, потому что он накладывал на меня еще больше этих ограничений.
Git говорит, что ветвление должно быть легким, но у многих компаний уже есть серьезная проблема с несанкционированными ветвями, поэтому я думаю, что ветвление должно быть важным решением со строгим контролем.Вот где перфорс действительно сияет...
В действительности вам редко нужны ветки, поскольку вы можете очень гибко манипулировать наборами изменений.Например, обычный рабочий процесс заключается в том, что вы синхронизируете последнюю заведомо исправную версию в основной сети, а затем пишете свою функцию.Всякий раз, когда вы пытаетесь изменить файл, разница этого файла добавляется в ваш «набор изменений по умолчанию».Когда вы пытаетесь проверить набор изменений, он автоматически пытается объединить новости из основной ветки с вашим набором изменений (фактически перебазируя его), а затем фиксирует.Этот рабочий процесс применяется без необходимости вашего понимания.Таким образом, Mainline собирает историю изменений, которую вы легко можете просмотреть позже.Например, предположим, что вы хотите вернуть старый, скажем, предпоследний.Вы синхронизируете момент перед изменением, вызывающим нарушение, отмечаете затронутые файлы как часть набора изменений, синхронизируете его с моментом после и объединяете с «всегда моим».(Там было что-то очень интересное:синхронизация не означает одно и то же - если файл доступен для редактирования (т. е.в активном наборе изменений) он не будет уничтожен синхронизацией, а помечен как подлежащий разрешению.) Теперь у вас есть список изменений, который отменяет нарушившее его изменение.Объедините последующие новости, и вы получите список изменений, который можно добавить поверх основной ветки, чтобы добиться желаемого эффекта.Мы ни разу не переписывали историю.
Теперь, предположим, что на полпути к вам кто-то подбегает и говорит вам бросить все и исправить какую-то ошибку.Вы просто даете своему списку изменений по умолчанию имя (фактически номер), затем «приостанавливаете» его, исправляете ошибку в теперь уже пустом списке изменений по умолчанию, фиксируете его и возобновляете именованный список изменений.Обычно несколько списков изменений приостанавливаются одновременно, когда вы пробуете разные вещи.Это легко и конфиденциально.Вы получаете то, что действительно хотите, от режима филиала, не поддаваясь искушению откладывать дела на потом или уклоняться от слияния с основной линией.
Я полагаю, что теоретически можно было бы сделать что-то подобное в git, но git делает возможным практически все, а не утверждает рабочий процесс, который мы одобряем.Централизованная модель представляет собой набор допустимых упрощений по сравнению с распределенной моделью, которая является неверным обобщением.Он настолько обобщен, что по сути ожидает, что вы внедрите поверх него систему контроля версий, как это делает репо.
Другое дело — репликация.В git возможно все, поэтому вам придется разобраться в этом самостоятельно.По сути, вы получаете фактически кэш без сохранения состояния.Единственная конфигурация, которую ему необходимо знать, — это местонахождение мастера, и клиенты могут указывать либо на мастер, либо на кэш по своему усмотрению.Это пятиминутная работа, и она не может пойти не так.
У вас также есть триггеры и настраиваемые формы для подтверждения проверок кода, ссылок на ошибки и т. д., и, конечно же, у вас есть ветки, когда они вам действительно нужны.Это не совсем понятно, но близко к этому, и его очень легко настроить и поддерживать.
В общем, я думаю, что если вы знаете, что будете работать централизованно, как это делают все, вы могли бы с таким же успехом использовать инструмент, разработанный с учетом этой цели.Git переоценен из-за устрашающего остроумия Линуса и склонности людей следовать друг за другом, как овцы, но его основной смысл существования на самом деле не противоречит здравому смыслу, и, следуя ему, git связывает себе руки. две огромные догмы о том, что (а) программное обеспечение и (б) данные должны быть одинаковыми как на клиенте, так и на сервере, и это всегда будет усложнять и усложнять централизованную работу.
Использование GIT вместо плохого управления строками кода является распространенным явлением. Многие из недостатков Perforce связаны с плохой стратегией ветвления. То же самое для любого другого централизованного инструмента. Если вам нужно создать кучу веток, вы делаете что-то не так. Почему разработчикам нужно создавать так много веток?
Кроме того, почему работа в любом случае так важна? Просто чтобы кто-то мог работать на поезде? Это единственное место, где вы не можете получить беспроводное соединение. И даже у большинства поездов есть приличный WiFi.
