Описание ограничений free версии доступно на сайте. Утверждений, что физическое число пользователей должно равняться чисто пользователей выделенных для free версии (5) - нет. Надо понимать, что при нормальном подходе один пользователь может создавать себе воркспейсы на разных машинах: рабочий стационарный, мобильный ноут, ещё один рабочий ПК в N-ом офисе и т.д. и т.п. Также всякие интеграции могут потребовать пользователя и воркспейс. В Perforce это прекрасно понимают. Маленькие проекты им неинтересны, а если проекты разрастаются - они сами осознают необходимость в покупке лицензии и приходят в Perforce.
Если бы у Perforce реально были бы такие проблемы, то ни одна из уважающих себя больших компаний (Ea, Epic Games, Ubisoft и другие), не работала бы с ним. Я много раз ставил P4. И на Linux, и на Win сервера. Самое просто конечно на Windows. Запустил инсталлер и всё. Далее можно только юзеров создавать и работать. Ваши кейсы звучат будто бы у вас локальная сеть была 512kbit и сплошные потери пакетов. Хотя даже Win Firewall иногда в это может вмешиваться, но и это легко заметить на этапе сетапе и тут же поправить. P4V - обязателен всегда к установке и всегда показывает ошибки соединения не создавая ложных иллюзий. А вот к плагину UE4 в этом плане много вопросов. Но если сеть стабильна, даже он показывает актуальный статус.
Кроссчекаут в перфорсе по умолчанию кстати не запрещён, но плагин анрила его как раз запрещает. Ну и на уровне конфига сервера это отключается также за 5 минут.
За мой 8 летний опыт работы с Perforce на разных проектах, с разными по размеру командами и до 100 человек и больше - никто не терял данные на чекауте. Скорее звучит так, что кто-то не делал чекауты (а настроенный в UE4 плагин делает это автоматом), файлы выводил из состояния read-only, работал с ними, а потом обновлялся, да ещё и в настройках воркспейса поставил галочку clobber writable files. Тут не VCS менять нужно, а человека увольнять.
Есть локальный воркспейс. Есть read only файлы. Художник/разработчик делает чекаут - заявляет серверу о своём праве работать с этим файлом за этим воркспейсом. Файл локально становится writable. Всё что происходит на сервере - в депоте файл помечается занятым и это отображается в других клиентах. Всё. Как это может привести к потере работы, я не понимаю. К любой гранате приложена инструкция.
На моём опыте, несчастные художники, куда больше бедокурили с Git и ещё больше с Git LFS. И это я пишу при всей своей любви к Git и Git Flow. Но увы не для UE4. Даже небольшой проект может разрастись в размерах и количестве бинарных файлов. Без LFS работа превратится в ад. А с LFS - появятся иные проблемы и скорость всё равно будет несопоставима с Perforce. Особенно если использовать клауд.
Ну кстати не обязательно Jenkins. От него мы как раз отказались в сторону BuildBot и большей свободы действий.
Что касается платности Perforce, то тут есть один неизвестный многим момент относительно Free версии. Perforce Server доступен для скачивания любым желающим и позволяет создать до 5ти бесплатных пользователей. А пользователи в свою очередь могут создавать себе отдельные ворксейспейсы (всего 20 воркспейсов во Free версии). Таким образом инди команды могут создавать пользователей с именами отделов (art, programming, design, sound, common) и раздавать этих пользователей соответствующим членам команды. Те в свою очередь на своих рабочих машинах будут заводить под общими юзерами именные воркспейсы. В конечном счёте от такого подхода команда практические ничем не пожертвует и это позволит одновременно трудиться на проекте 20 членам команды, что для многих инди команд весьма солидный размер.
Для больших проектов конечно потребуется таки купить юзеров, но на то они и большие - у них должно быть должное финансирование и VCS тут явно не повод для экономии.
Выбор VCS для UE4 должен зависеть от размера команды и сложности проекта, а не от предпочтений отдельно взятых разработчиков. Для больших проектов, с большим количеством художников (да и разработчиков, если те злоупотребляют блупринтами) и с большим количеством ассетов, просто необходим Perforce. P4 работает с репозиториями любых размеров и отслеживает чекауты взятых в работу файлов. Уже хотя бы этих двух ключевых моментов достаточно, чтобы перестать насиловать команду с Git LFS или SVN, а кое-где сразу в связке (реальный кейс одной из компаний). А возможностей по автоматизации через P4 море. Ну и недаром сами Epic Games даже казалось бы, только с кодом движка, работают через Perforce (а в Git выгружают только для Community и пулл реквестов).
А ты настолько неудачник, что при каждом случае когда тебе нечего ответить, прибегаешь к попытке оскорбить человека. Сразу видно уровень — автор с большой буквы) Иди и дальше плачь по своей фиче… И пиши про то, какой гугл плохой… Ай ай ай… Еще напиши обязательно про несправедливость мира сего) Нам всем очень интересно)
Обделался тут только набравший минусов гореписатель) И благодаря своим комментариям он еще больше утопает в своем дерьме) Продолжай в том же духе, забавно смотреть)
Лол) Если по твоему, твой читатель ввиду недостатка фактов статье еще и обязан проверять даты статей на которые ты же сам и ссылаешься, то удачки тебе в журналистике и первенству по сбору минусов)
Вы лучше бы удивлялись своей тупизне и отсутствию структуры повествования. Сперва написали «статью» из двух абзацев, абсолютно не раскрыв сути своего же заголовка, не объяснив в двух словах предысторию этой «супер важной» фичи, про которую здесь большинство слышат в первый раз. Потом удивляетесь, что люди привыкшие к определенному уровню качества статей на данном ресурсе предъявляют вам претензии. С такими талантами, вам только на kanobu писать. Там таких нынче любят.
Хм… То есть, вы по вашему с точки зрения журналистики это нормально в абзаце начинающемся со слова «суть» не описать самой сути ситуации с самого ее начала? В вашем контексте смысл слова «опять» абсолютно теряется и не рассматривается, как нечто случившее снова. Наоборот, то произошло прежде остается за кадром вашей статьи. И потом вы удивляетесь критике?)
Я про ту статью, на которую вы и сами сослались, поэтому да, «что за глупизна?»
We’ve been listening to user feedback since the graduation and have decided to move the feature back into Gmail Labs. Users sometimes unintentionally quoted text they had inadvertently selected, which caused some confusion.
Что за желтизна? В оригинальной статье все предельно ясно объясняется — 50 дней назад фичу перенесли из Gmail Labs в Gmail по умолчанию, но из-за того, что данная фича вызывала путаницу у многих юзеров, ее убрали обратно в Labs, а не удалили совсем.
Открывая статью рассчитывал получить более-менее объективное сравнение и не только на одном единственном тесте. На единственном тест кейсе невозможно построить объективные выводы разработки проекта в продакшн. Более того, нет упоминаний о версиях движков и моделях девайсов. От некоторых очень смелых выводов хочется запостить ту известную картинку с Джеки Чаном, но я сейчас пишу этот коммент не за этим. Просто ради установления справедливости, пройдусь по нескольким моментам из статьи (оригинальная в данный момент к сожалению не доступна).
Джеки Чан №1:
Серьезно не хватает документации по C++
Складывается впечатление, что либо автор статьи пользуется другим источником документации для UE4, либо никогда не открывал документацию для Unity3D или (о ужас!) CryEngine. Интересно, чтобы он сказал тогда. К слову, у меня еще ни разу не возникло нюансов с недостатком документации и я считаю, что нет ничего проще чем самому заглянуть в тело метода и прочесть, что же именно он делает, если по какой-то причине недоступно его описание.
Джеки Чан №2:
UE4 поддерживает сборку для устройства с iOS лишь при условии, что ваше приложение состоит только из чертежей.
Это вина Apple
Я все же надеюсь, что это тонкости перевода, но с этой фразы я чуть не поперхнулся чаем, который пил в момент прочтения) На iOS невозможно собрать C++ UE4 проект и в этом виноваты Apple? Really?) Суть в том, что для сборки C++ проектов под iOS необходимы непосредственно OS X и Xcode. Как и в случае с Unity проектами под iOS. В противном случае из под винды можно собрать только BP проект. Строить из этого вывод, что под UE4 вовсе невозможна разработка на C++ для iOS – очень нелепо.
Проект Unity существенно компактнее чем Unreal
Здесь важны оговорки, во-первых в UE4 в проект по умолчанию билдятся все модули, которые совершенно точно не использовались в тестовом проекте. В Unity stripping делается автоматически, в UE4 же это необходимо дефайнить модули вручную в C++ проекте, который у автора «не билдится под iOS». Также по умолчанию во все проекты добавляется около 30мб ресурсов необходимых для Slatе. Это также отключается с помощью конфига. Во-вторых авторы не упомянули о раздувании размера Unity проектов на iOS при использовании IL2CPP рантайма, что теперь (с 1 июня 2015 года) обязательно если вы хотите опубликовать приложение в AppStore (IL2CPP поддерживает архитектуру ARMx64, а та устаревшая версия mono, которая используется в Unity — нет). Опять же, почему автор не привел версии движков, OS и моделей девайсов – не понятно.
Также хочу добавить, что не увидел о Unity3D минусов связанных с ужасной нестабильностью всех последний релизных версий движка на iOS, с ужасным количеством багов, которых с каждой новой версией становилось только больше на протяжении последнего полугода. Лишь только последнем патче для 5.2.1 удалось добиться более менее неплохой стабильности от IL2CPP бэкенда. Складывается впечатление, что у автора не было опыта разработки большого проекта на Unity под iOS, либо опыт был, но задолго до перехода Apple на обязательную x64 архитектуру для приложений.
P.S. Я не призываю к холивару – я призываю к объективности и осторожности с выводами.
Это приложение позволяло не только слушать, но и скачивать музыку на девайс. Тоже пользовался им однажды – отсутствие нормального oauth входа тогда очень смутило, но положительные отзывы и желание поставить любимую мелодию на рингтон возобладали над здравым смыслом. Правда было это уже больше года назад. Возможно тогда данных ещё не собирали :)
В этом также нет и вины Epic Games. CLion как любая конкурентоспособная IDE должна уметь из кастомных скриптов собирать, т.е. запускать процессы с аргументами. Возможность указывать в сборке запуск процессов позволяет настраивать в IDE компиляцию любых проектов.
В Qt Creator я компилировал кастомными скриптами приложение под андроид – у меня java код компилировался (в ide для c++), была сборка, запаковка apk, подпись, установка и запуск приложения. Я тоже самое мог бы сделать и в xcode например. В нем я компилировал qt проекты с помощью qmake, при этом xcode ничего не знает про qt.
Было бы интересно узнать мнение, а может быть и планы JetBrains по этому поводу.
Описание ограничений free версии доступно на сайте. Утверждений, что физическое число пользователей должно равняться чисто пользователей выделенных для free версии (5) - нет. Надо понимать, что при нормальном подходе один пользователь может создавать себе воркспейсы на разных машинах: рабочий стационарный, мобильный ноут, ещё один рабочий ПК в N-ом офисе и т.д. и т.п. Также всякие интеграции могут потребовать пользователя и воркспейс. В Perforce это прекрасно понимают. Маленькие проекты им неинтересны, а если проекты разрастаются - они сами осознают необходимость в покупке лицензии и приходят в Perforce.
Если бы у Perforce реально были бы такие проблемы, то ни одна из уважающих себя больших компаний (Ea, Epic Games, Ubisoft и другие), не работала бы с ним. Я много раз ставил P4. И на Linux, и на Win сервера. Самое просто конечно на Windows. Запустил инсталлер и всё. Далее можно только юзеров создавать и работать. Ваши кейсы звучат будто бы у вас локальная сеть была 512kbit и сплошные потери пакетов. Хотя даже Win Firewall иногда в это может вмешиваться, но и это легко заметить на этапе сетапе и тут же поправить. P4V - обязателен всегда к установке и всегда показывает ошибки соединения не создавая ложных иллюзий. А вот к плагину UE4 в этом плане много вопросов. Но если сеть стабильна, даже он показывает актуальный статус.
Кроссчекаут в перфорсе по умолчанию кстати не запрещён, но плагин анрила его как раз запрещает. Ну и на уровне конфига сервера это отключается также за 5 минут.
За мой 8 летний опыт работы с Perforce на разных проектах, с разными по размеру командами и до 100 человек и больше - никто не терял данные на чекауте. Скорее звучит так, что кто-то не делал чекауты (а настроенный в UE4 плагин делает это автоматом), файлы выводил из состояния read-only, работал с ними, а потом обновлялся, да ещё и в настройках воркспейса поставил галочку clobber writable files. Тут не VCS менять нужно, а человека увольнять.
Есть локальный воркспейс. Есть read only файлы. Художник/разработчик делает чекаут - заявляет серверу о своём праве работать с этим файлом за этим воркспейсом. Файл локально становится writable. Всё что происходит на сервере - в депоте файл помечается занятым и это отображается в других клиентах. Всё. Как это может привести к потере работы, я не понимаю. К любой гранате приложена инструкция.
На моём опыте, несчастные художники, куда больше бедокурили с Git и ещё больше с Git LFS. И это я пишу при всей своей любви к Git и Git Flow. Но увы не для UE4. Даже небольшой проект может разрастись в размерах и количестве бинарных файлов. Без LFS работа превратится в ад. А с LFS - появятся иные проблемы и скорость всё равно будет несопоставима с Perforce. Особенно если использовать клауд.
Ну кстати не обязательно Jenkins. От него мы как раз отказались в сторону BuildBot и большей свободы действий.
Что касается платности Perforce, то тут есть один неизвестный многим момент относительно Free версии. Perforce Server доступен для скачивания любым желающим и позволяет создать до 5ти бесплатных пользователей. А пользователи в свою очередь могут создавать себе отдельные ворксейспейсы (всего 20 воркспейсов во Free версии). Таким образом инди команды могут создавать пользователей с именами отделов (art, programming, design, sound, common) и раздавать этих пользователей соответствующим членам команды. Те в свою очередь на своих рабочих машинах будут заводить под общими юзерами именные воркспейсы. В конечном счёте от такого подхода команда практические ничем не пожертвует и это позволит одновременно трудиться на проекте 20 членам команды, что для многих инди команд весьма солидный размер.
Для больших проектов конечно потребуется таки купить юзеров, но на то они и большие - у них должно быть должное финансирование и VCS тут явно не повод для экономии.
Выбор VCS для UE4 должен зависеть от размера команды и сложности проекта, а не от предпочтений отдельно взятых разработчиков. Для больших проектов, с большим количеством художников (да и разработчиков, если те злоупотребляют блупринтами) и с большим количеством ассетов, просто необходим Perforce. P4 работает с репозиториями любых размеров и отслеживает чекауты взятых в работу файлов. Уже хотя бы этих двух ключевых моментов достаточно, чтобы перестать насиловать команду с Git LFS или SVN, а кое-где сразу в связке (реальный кейс одной из компаний). А возможностей по автоматизации через P4 море. Ну и недаром сами Epic Games даже казалось бы, только с кодом движка, работают через Perforce (а в Git выгружают только для Community и пулл реквестов).
Джеки Чан №1:
Складывается впечатление, что либо автор статьи пользуется другим источником документации для UE4, либо никогда не открывал документацию для Unity3D или (о ужас!) CryEngine. Интересно, чтобы он сказал тогда. К слову, у меня еще ни разу не возникло нюансов с недостатком документации и я считаю, что нет ничего проще чем самому заглянуть в тело метода и прочесть, что же именно он делает, если по какой-то причине недоступно его описание.
Джеки Чан №2:
Я все же надеюсь, что это тонкости перевода, но с этой фразы я чуть не поперхнулся чаем, который пил в момент прочтения) На iOS невозможно собрать C++ UE4 проект и в этом виноваты Apple? Really?) Суть в том, что для сборки C++ проектов под iOS необходимы непосредственно OS X и Xcode. Как и в случае с Unity проектами под iOS. В противном случае из под винды можно собрать только BP проект. Строить из этого вывод, что под UE4 вовсе невозможна разработка на C++ для iOS – очень нелепо.
Здесь важны оговорки, во-первых в UE4 в проект по умолчанию билдятся все модули, которые совершенно точно не использовались в тестовом проекте. В Unity stripping делается автоматически, в UE4 же это необходимо дефайнить модули вручную в C++ проекте, который у автора «не билдится под iOS». Также по умолчанию во все проекты добавляется около 30мб ресурсов необходимых для Slatе. Это также отключается с помощью конфига. Во-вторых авторы не упомянули о раздувании размера Unity проектов на iOS при использовании IL2CPP рантайма, что теперь (с 1 июня 2015 года) обязательно если вы хотите опубликовать приложение в AppStore (IL2CPP поддерживает архитектуру ARMx64, а та устаревшая версия mono, которая используется в Unity — нет). Опять же, почему автор не привел версии движков, OS и моделей девайсов – не понятно.
Также хочу добавить, что не увидел о Unity3D минусов связанных с ужасной нестабильностью всех последний релизных версий движка на iOS, с ужасным количеством багов, которых с каждой новой версией становилось только больше на протяжении последнего полугода. Лишь только последнем патче для 5.2.1 удалось добиться более менее неплохой стабильности от IL2CPP бэкенда. Складывается впечатление, что у автора не было опыта разработки большого проекта на Unity под iOS, либо опыт был, но задолго до перехода Apple на обязательную x64 архитектуру для приложений.
P.S. Я не призываю к холивару – я призываю к объективности и осторожности с выводами.
В Qt Creator я компилировал кастомными скриптами приложение под андроид – у меня java код компилировался (в ide для c++), была сборка, запаковка apk, подпись, установка и запуск приложения. Я тоже самое мог бы сделать и в xcode например. В нем я компилировал qt проекты с помощью qmake, при этом xcode ничего не знает про qt.
Было бы интересно узнать мнение, а может быть и планы JetBrains по этому поводу.