Войти
ПрограммированиеФорумСеть

Собственная система контроля версий и командной разработки

#0
(Правка: 13:32) 12:04, 20 ноя. 2020

Попробую озвучить и собрать мысли в этой тебе по поводу того что я хочу сделать.

А хочу я не много ни мало систему для совместной разработки, для проектов на UE4, может быть и для Unity, кто знает.

В UE4 уже есть поддержка Perforce, казалось бы, можно использовать. Но что меня не устраивает в Perforce?:
1) Perforce универсальный инструмент, это значит его нужно настраивать для каждого конкретного проекта, но основная проблема в том, что настройками на стороне сервера не ограничишься, приходится при установке клиента тоже немало страдать. Предположим я нашел в команду нового разработчика, и ему нужно установить клиент для командной работы, в Perforce ему придется выполнить немало пунктов по настройке клиента, там черт ногу сломит.
2) Perforce отличается от Git тем что использует CheckIn/Out. А я настолько привык к философии Git, что не понимаю зачем эти чекины кому то вообще нужны. Я хочу чтобы коммиты отправлялись на сервер тогда, когда я этого захочу. А каждый разработчик должен самостоятельно следить за своей областью файлов, поэтому мержинг как таковой может вообще не понадобиться.
3) Perforce реально багованный и неудобный.

Что я хочу добиться в своей системе?:
1) Прежде всего простоты, никаких универсальных фич, никаких лишних фич. По моим прикидкам вначале будет всего 2 кнопки: Update (скачивает с сервера последнюю версию проекта и редактора), Commit (отправляет все измененные разработчиком файлы на сервер). Даже Revert я сразу не планирую добавлять.
2) Разработчику не нужно никаких ignore листов, система будет заранее знать какие в проекте могут быть типы файлов, какие файлы нужно коммитить, какие игнорировать и так далее, это я сам всё настрою при разработке этой программы.
3) Я не пытаюсь создать мега мощную универсальную систему контроля версий, я хочу лишь чтобы группа из нескольких человек имела простую возможность работать над одним проектом, и чтобы для этого им не пришлось ломать голову как это всё установить и настроить. Скачал DevClient, запустил, авторизовался, указал рабочую папку, всё, проект скачался, запустил UE4 редактор и работаешь.


По началу я сделаю так, что нужно будет перед Update закрывать UE4 редактор, потому что нельзя так просто на лету перезаписать некоторые файлы, которые открыты в редакторе, включая сам редактор. Но в последствии можно сделать так, что если обновляется только контент проекта, то не обязательно закрывать редактор. Это можно сделать посредством плагина для UE4, и в самом UE4 есть исходник реализации как это сделано для Perforce, смысл в том, что там нужно закрывать открытые паки, и потом заново их открывать, когда обновление установится, тем самым файлы обновятся не закрывая редактор. Как всегда открытые исходники UE4 рулят.

Мой DevClient будет автоматически следить за тем, у кого какие разрешения, и какие файлы коммитить, а какие не трогать. Допустим у разработчика роль моделлера, у него разрешение изменять файлы только в папке Models, соответственно при нажатии кнопки Commit, будут учитываться измененные файлы только из этой папки, даже если он изменил файлы в других папках. А если, разработчик нажмет Update, то его измененные файлы в папке Models не будут обновлены, как минимум без его согласия или в зависимости от настроек и версии файлов. А вот все остальные файлы и папки будут изменены чтобы совпадать с версией на сервере. Например доступа к C++ исходникам у обычных разработчиков тоже не будет. Роли разработчикам будет давать админ, и регистрировать пользователей тоже будет админ.

По началу это будет больше напоминать просто систему синхронизации файлов с сервером, но постепенно можно добавить небольшой контроль версий и функцию Revert. А потом еще что нибудь. Но по началу это всего лишь способ синхронизации для небольшой команды, без необходимости разбираться в контроле версий, всяких там мержингах, бренчах и прочее.

В итоге должно получиться 2 программы на C#: DevServer и DevClient, а в последствии еще и плагин для UE4. Клиент может работать со старой версией, вообще не нажимая Update, хоть целый день, просто потом ему желательно скачать последнюю версию и проверить что его новый контент работает как надо, перед тем как посылать Commit.

DevServer:
  принимает пользователей по TCP + SSL (но это не точно)
    информация о пользователях будет храниться просто в самодельном бинарном файле.
    тоже самое касается логов - просто файлы.
  админ тоже соединяется как обычный пользователь, только права другие:
    может закачивать на сервер обновления для DevServer и DevClient.
  при получении обновления DevServer:
    останавливается, можно подождать пока все загрузки завершатся, но не принимать новые запросы.
    самообновляется
    самоперезапускается
  при получении обновления DevClient:
    сообщает пользователям о наличии новой версии клиента.
    клиенты автоматически скачивают новую версию при запуске клиента, но только после авторизации ибо клиент можно сказать проприетарный.
  отправляет обновление при нажатии пользователем Update.
  принимает Commit:
    кто сделал коммит
    текст коммита
    версия (индекс) коммита // каждый коммит можно сохранять в отдельную папку с этим индексом, чтобы потом можно было делать Revert.
    манифест коммита
    файлы коммита
  отправляет сообщения другим пользователям что пользователь: online/offline.
  отправляет сообщения что: такой то пользователь сделал коммит, версия сборки изменилась и можно нажать Update.

DevClient:
  авторизуется с помощью login + password, или developerKey, или token если мы уже авторизованы и сказали "не выходить". Но скорее всего для безопасности я потребую постоянно вводить login + password.
  админ может закачивать на сервер новые версии для: DevServer/DevClient, через этот самый клиент, не важно уже новый или старый (если это невозможно из-за ошибок в клиенте, тогда ручками через менеджер сервера, но этого не должно случиться).
  возможность самообновления DevClient (скачивание + установка с перезапуском).
  кнопка Update + индикатор что новое обновление доступно.
  кнопка Commit + текст коммита
  окно лога, вместо всяких всплывающих сообщений, мы же разработчики.

Это начальная версия, впоследствии можно добавить возможность делать Commit локально, без моментального отсыла на сервер, а также локально потом делать Revert.

Мне всё таки кажется, что функционал не такой огромный и сложный, чтобы считать эту затею избыточной. Я много раз пытался использовать Perforce, и каждый раз с треском его удалял, просто мне это надоело.

А и еще, в Perforce что меня взбесило, это то что если я хочу добавить файл, мне нужно выделить этот файл в самом Perforce и выбрать Add, тоже самое, если я хочу пометить файл на удаление. У меня всё будет делаться "по людски", при нажатии Commit - файлы будут автоматически проверяться на физическое наличие или отсутствие, и автоматически добавляться или удаляться с проекта, не надо нажимать никаких "обновить список файлов", "пометить файл на добавление", "пометить файл на удаление" и прочую ересь. Можно будет просто добавить или удалить файл через проводник, и всё будет добавлено или удалено автоматически.

PS: исходный код проекта кстати будет использовать отдельно Git, моя система разработки чисто для контента и редактора. Но благо для обычных разработчиков в команде доступ к коду не нужен, им достаточно редактора и всё что в нём, а в моем случае кодом занимаюсь чисто я один, остальные получают уже готовую DLL.


#1
9:55, 21 ноя. 2020

Идея неплохая и даже рабочая. На одно рыло локальную приблуду для гита делал, пользуюсь, результат нравится. Для проекта на одно человекоместо даже графическая оболочка не обязательна, можно кликать мышкой по нескольким скриптам запускающим с ключом бинарник, а потом читать текст в выскакивающей консоли и жать на нужную клавишу для подтверждения процесса и после его завершения. Цель ведь ограничить возможности гита чтобы не было ай-яй-яй, которые замучаешься разруливать. А для этого нужно выполнять ограниченное количество операций и не давать гиту лишней информации, чтобы он не запрещал действия. Делаешь бинарник, который запускает несколько баш/цмд скриптов  (для очистки проекта от временных файлов, добавления файлов в проект, их удаления оттуда), читает конфиг, в котором содержится номер версии и комент, который нужно добавить в коммент коммита. Добавлять туда можно длиннющие строки, только их нужно разбивать на куски байтами #13#10, на случай, если длинные строки на русском после команды git log напополам поломает.

Бинарник читает конфиг, запускает нужные скрипты увеличивает номер версии на единицу, делает коммит, в котором пишет в коммент номер версии, добавляет к нему разбитый на куски коментарий из конфига, а после переписывает конфиг с новым номером версии. git push вручную делал. А если нужно из гита версию скачать, то клонировал гит в другой каталог, брал оттуда нужные файлы и ручками переносил их в проект, чтобы гит не стал права качать на тему "это ветка и т.д., ничего коммитить в мастер не буду".  Комментарий к сохраняемой версии редактировал прямо к конфиге, но если делать графический интерфейс, то можно всё делать в нём.

Это минимальный набор фич на одно рыло, тестировать систему можно начать с него, а потом добавлять других пользователей, админа и сеть.

#2
2:53, 27 дек. 2020

Можно подумать о связке git/gerrit или git/github с платным аккаунтом

#3
13:40, 27 дек. 2020

Сделай умоляю)) как же нужна данная функция..
Я уже ранее писал об этом и понял, что эпикам срать а внешние проги сложны и геморны все..
Если сделаешь прям 5к перешлю сразу:))

#4
13:53, 27 дек. 2020

gamedeveloper01
> Я хочу чтобы коммиты отправлялись на сервер тогда, когда я этого захочу.

у ты какой ... а если Вася ждёт апдейтфикс твоего кода?

#5
18:05, 27 дек. 2020

gamedeveloper01
> По моим прикидкам вначале будет всего 2 кнопки: Update (скачивает с сервера
> последнюю версию проекта и редактора), Commit (отправляет все измененные
> разработчиком файлы на сервер).
Но это же SVN.

#6
9:34, 28 дек. 2020

gamedeveloper01
> 3) Perforce реально багованный и неудобный

забавно, я работал с UE4+P4, потом перешёл на git и так плевался :)

#7
16:48, 16 фев. 2021

gamedeveloper01
> каждый разработчик должен самостоятельно следить за своей областью файлов
Как в Visual Source Safe - когда чекинишь файл, он скачивается тебе на комп и можешь редактировать, а для остальных на сервере read-only, с пометкой кто захватил

#8
17:21, 16 фев. 2021

я бы смотрел на системы контроля версий и игры с точки зрения не решённых проблем:
1. бинарники - просто название файла для отката ни о чём не говорит нужна система с предпросмотром(как в случае с кодом)
2. система ограничения доступа роу бинарникам: автоматически подменять ресурсы на "пустышки"(скажем текстуры на текстуры с отображением плотности текселей, а модели на лод 3-4) для удалённой разработки ИМХО нужная штука была бы.

#9
(Правка: 16:21) 15:32, 15 июля 2021

Aslan
> Как в Visual Source Safe - когда чекинишь файл, он скачивается тебе на комп и
> можешь редактировать, а для остальных на сервере read-only, с пометкой кто
> захватил
Не, немного не так. У меня разработчик ничего не чекинит, просто если кто то другой попытается изменить у себя этот файл, и потом его залить, то если у него нет прав, вместо того чтобы залить этот файл, он скачает заново оригинал с сервера или просто ничего не зальет (в зависимости от выбора или настроек). А если у него как и у тебя есть права, то залив выполняется в порядке живой очереди. А сам процесс заливки (коммит), будет требовать сначала проверить не изменились ли на сервере файлы, которые ты хочешь изменить, если изменились, то тебя еще раз спросят, хочешь ли ты их перезаписать, или наоборот заменить свои файлы на новые с сервера. В целом это должен быть редкий случай (collision), когда файлы, которые ты изменяешь, уже кто то изменил. То есть в моей системе не будет никакого позднего -merge(разрешения конфликтов) как в Git, будет всё решаться сразу при загрузке коммита, либо всплывающим окном, либо предварительными настройками. То есть весь процесс синхронизации и разрешения конфликтов будет выполняться в момент коммита, нечто среднее между чекинами и Git merge.

uss
> 1. бинарники - просто название файла для отката ни о чём не говорит нужна
> система с предпросмотром(как в случае с кодом)
Код я пока контролю Git, а своя система нужна как раз для бинарников и контента, которые в большинстве случаев не нуждаются в Diff отображении, поэтому можно это и не делать. Просто загрузил посмотрел, не понравилось откатил. А вот Diff отображение измененной структуры файлов и каталогов не помешает.

uss
> 2. система ограничения доступа роу бинарникам: автоматически подменять ресурсы
> на "пустышки"(скажем текстуры на текстуры с отображением плотности текселей, а
> модели на лод 3-4) для удалённой разработки ИМХО нужная штука была бы.
Идея конечно неплохая, но как то не вижу смысла. У меня вся защита при удаленной разработке будет основана на сокрытии кода от разработчиков (будут .dll), а вот контент для чтения будет доступен для всех, для изменения уже в зависимости от прав, но не в сыром виде, а уже в виде ассетов для UE4. У каждого пользователя еще могут быть "индивидуальные файлы" или "папка", куда  он сможет вершнконтролить свои "сырые" файлы (майя, фотошоп или что там еще), которые будут видны только ему или кому он разрешит.

PS: я уже пол года не занимался проектом, но в ближайшее время планирую возобновить и надеюсь доделать.

PS2: я как раз недавно думал по поводу того, как в моей системе будут реализованы "ветки". В основном все рабочие коммиты будут сразу поступать в master ветку. Если же разработчик хочет просто "сохраниться", но при этом не хочет коммитить в мастер ветку, то у каждого разработчика в системе будет своя "temporary" ветка, в которую будут сохраняться все "временные" коммиты, которые он потом уже сможет окончательно закоммитить. Если же разработчик захочет создать отдельную "именованную" ветку, например для какого то там теста, то у него тоже должна быть такая возможность. У каждой именованной ветки будет своя дополнительная temporary ветка соответственно. Создатель именованной ветки сможет раздавать права по изменению ветки другим разработчикам на своё усмотрение. Все слияния веток в мастер ветку будут происходить по тому же принципу, что и обычные коммиты. Однако "именованные" ветки не так необходимы, особенно для маленьких проектов, а вот "временная" ветка обязательно должна быть реализована, иначе разработчик не сможет сохранять прогресс в облаке, только локально, а делать частые, да еще и нерабочие коммиты в мастер ветку - не вариант. Скорее всего если я и сделаю "именованные" ветки, то не совсем обычные, они не будут считать все файлы неизменными начиная с момента разветвления, а будут также учитывать обновленные файлы с мастер ветки, и лишь файлы, которые добавлены в ветку будут заменять собой файлы из мастер ветки, либо заранее установленный список файлов и папок при создании ветки, грубо говоря у каждой ветки будет свой .ignore файл, который сможет менять только админ ветки, и все файлы которые игнорируются веткой, будут обновляться с мастер ветки. Фичи фичами, а общий прогресс нужно учитывать во всех ветках я считаю. Но в целом, я не особо вижу смысла в "именованных" ветках для маленьких проектов, во всяком случае мне они не особо нужны, поэтому в начальной версии скорее всего их не будет, и тогда разработчику вообще ничего не нужно будет знать о ветках, будет просто "сохранить"(или временный коммит) и "коммит".

#10
18:46, 15 июля 2021

gamedeveloper01
> Perforce реально багованный и неудобный
Алекса на тебя нет
https://gamedev.ru/flame/forum/?id=259692

ПрограммированиеФорумСеть