Цитата:
Сообщение от
Андре
Выкладывать обе версии - пообъектную и собранную. Ну или job, который будет собирать полную версию.
все говорят про "узлы АОТ".
собственно говоря, я и хочу понять - а почему так правильно?
не удобнее ли с точностью до методов?
и раз уж выкладывать и пообъектную, и собранную (и огребать проблемы с конфликтом правок)
то можно выкладыдать и методы. не так ли?
ведь каталог CIL кодом сейчас содержит туеву хучу фаликов для каждого метода.
и ничего, живет.
Цитата:
Сообщение от
Андре
Бранчи.
а почему бранчи, а не подкаталоги, например? или не отдельные проекты?
я не ехидничаю, я действительно не знаю и хотел бы услышать аргументы.
Цитата:
Сообщение от
Андре
Не вижу здесь никакой специфики Ax.
согласен. но не совсем.
просто для каждого языка (ну, или для каждой платформы уже есть устоявшиеся соглашения). например, исходный код в каталоге src, юнит-тесты в каталоге test, документация в каталоге doc.
а вот, например, с зависимыми проектами уже общих соглашений нет. кто называет каталог dependences, кто ext, кто packages.
Я думал, что может кто уже размышлял на тему что нужно выкладывать для аксапты. Хотел послушать.
вот какая общая структура каталогов у меня пока получается для аксаптовских проектов
- aot\Data Dictionary ...\Classes\Job\Resources\... - мелкие xpo с точностью до узла АОТ и/или подробнее с точностью до метода.
- data - внешние данные, необходимые для работы
- ?Dependencies
- doc
- ?ext
- examples
- labels
- lib
- make - как собрать/внедрить/имплементировать. например, в проект не стоит вкладывать меню Ledger|Aministration, поскольку в каждом конкретном случае эти меню будут сильно кастомизированы. Лучше написать инструкцию "вставить menuItem туда-то". Подобные действия стоит описать в этом каталоге
modules
- projects - private/shared проекты одним файлом, который можно непосредственно импортировать в аксапту (на codeplex есть понятие "релиз". это файл, который может загрузить пользователь и юзать без исходного кода. собственно оно и есть)
packages
- resource\client...\server...\include\template...\script
- setup - установка
- support
- test
- .gitmodules -- http://git-scm.com/book/ru/v1/%D0%98...83%D0%BB%D0%B8
каждый проект - это отдельный полностью компилируемый блок, который может использовать другой проект, указанный в модулях.
примерно так...
Цитата:
Сообщение от
Андре
Гораздо хуже то, что главное в Git (а тем более GitHub) - это коллективная работа, когда разработка ведется параллельно разработчиками в нескольких системах, а потом все изменения сливаются вместе. Cделать полноценный merge с разрешением конфликтов в связке Ax+Git я, когда этим занимался не смог. А это убивает всю социальную составляющую.
а почему?
можешь подробнее?
Цитата:
Сообщение от
Андре
p.s. И приведенные тобой репозитории наглядно демонстрируют эту проблему. Посмотри на список коммитов - все эти проекты разрабатываются одним человеком. Как послать туда pull request нормально, я даже не представляю.
ВОТ!
собственно вопрос - а как сделать так, чтобы было нормально?
чтобы было удобно?
чтобы было правильно?
что нужно объяснить людям? что написать в FAQ? (например, меня останавливало масса мелких xpo-шников, про combinexpos я только здесь узнал. а собирать руками - это "ну его нафиг". если бы я знал об этой тулзе раньше!)
собственно вопрос:
Как правильно обмениваться аксаптовскими проектами [, которые содержат только нестандартные объекты]?