Распределенная разработка

[blokva]

Вставлю пятачок...
В разЫ повышается скорость объединения распределенных доработок, если разработчики везде и всегда пишут подробные комментарии.

[mit]

db, спасибо что обратили внимание, хорошее заменяние.
да, со сравнением элементов с одинаковыми id объектов проблема в 2.5. была. возможно в 3.0. она осталась, но олд папка это не панацея от всех бед, это дополнительный инструмент контроля. то, что описал db можно избежать путем введения простых правил использования объектов внутри команды. кстати бэст практикалс описывает почти все что нужно. но чаще всего требуется контролировать (у нас) не свойства объектов а именно изменения логики.

[Sada]

У нас было так:
и заказчик и внедренец лобали код в одном слое, у всех был одинаковый слой.
Минимальное изменение в слое тут же пересылалось сторонами и заливалось.
Получалось вполне прилично. Но все же один раз получилась ошибочка - мою мааааленькую модификацию поторли - но это было совсем не критично. Может кому поможет мой "пятачок"(c) blokva

[Maxim Gorbunov]

Цитата:

Сообщение от db

5. сравниваем table1 и old\table1 - как ни странно НИКАКИХ различий нет

И это правильно
Вспоминаем, что с точки зрения описания свойств поля таблицы внешним ключом является TypeId, а не имя типа. Соответственно, в свойствах таблицы никаких изменений не произошло: как было поле с типом 50005, например, так оно и осталось.

Для закрепления знаний сравним тип 50005 с его версией, сохраненной на old-слое (не забываем сбросить галочку suppress name property при сравнении). Убеждаемся, что имя для EDT - такое же свойство, как, например, и Alignment. Если Alignment у EDT поменялся, вы не увидите этого, сравнивая новую и старую версию таблицы. То же самое происходит и с именем.

В общем, про old-слои забывать не нужно. Надо ими правильно пользоваться.

[db]

Можно я пофлудю на пару страничек?

Максим, Вы всерьез верите в то, что написали?
Очень похоже на стиль отписок из техподдержки майкрософта. Вы там случайно не работаете
Типа все работает by design, а то что design кривой то это не наши проблемы

Как понимание того, что ключ изменился или не изменился поможет человеку в реальной работе по подъему
кода? Логично предположить, что человек, занимающийся сравнением кода между слоями
хочет видеть все изменения, которые произошли и не видеть того, чего на самом деле нет.
И изменился там ключ, не изменился в данном случае
не должно играть никакой роли. Ибо использование ид в качестве общего ключа двух РАЗНЫХ приложений
выглядит несколько странным.
Если система врет (а она врет), предоставляя
неверные данные, то каков будет результат работы, основанный на таких данных?

Настоящее веселье начинается не при переименовании элементов, а при совпадении ид у разных элементов
(отличающихся не только именами) между старым и новым приложением.

Если у меня в старом приложении У таблицы table1 поле field1 имело тип type1
а в новом это же поле имеет type2 в результатах сравнения я хочу это видеть.
И не чесать репу, почему это вдруг показывается что в старом приложении поле не имело никакого EDT
(так показывается, если в новом приложении edt c ид от type1 нет)
И не чесать репу, думая что за идиот сменил у поля edt type1 на mysupertype (так показывается, если в новом приложении
mysupertype имеет тот же ид, что был у type1 в старом)
...
Список возможных вариантов можно легко продолжить

При подъеме кода уже через час работы сидишь как обкуренный и дополнительная мыслительная деятельность здесь явно ни к чему.

Скажете это все редкие случаи? И если иногда будет криво, то и пусть? Если так, то это очень похоже, например,
на работу циркуляркой с треснутым диском. Авось отпилим. Только все время будет ожидание, что пила вот вот развалится.
Будем ее проверять, рассматривать и молиться что не получим куском пилы в лоб

Основных проблем здесь две
1. элементы с одним ид в разных приложениях считаются одним и тем-же (ну это скорее проблема дизайна)
2. при вытаскивании свойств элементов старого приложения, являющихся ссылками на другие элементы с собственным ид, поиск имени этого элемента, возвращаемого в AotGetProperties идет почему то не в старом, а в новом приложении (а вот это уже 100% баг). И никакая галочка "Подавлять свойства" здесь не спасет.

Ваш пример со сравненеим переименованного типа как раз работает правильно (если не учитывать проблему 1),
и даже выдает различие имен, но проблема не со сравнением EDT нового и старого, а со сравненеием старый/новый
другого элемента, ссылающегося на этот EDT

Всем удачных праздников, а мне очердного удачного запуска
Чего только со скуки не напишешь

[Maxim Gorbunov]

Верю. На самом деле. К Майкрософту отношения не имею.

По пунктам:
1. То, что дизайн Вам не нравится, еще не значит, что он кривой. Он вот такой, какой есть.
2. При обновлении приложения в первую очередь нужно учитывать особенности архитектуры.
3. Учитывая особенности архитекутры, поле field1 таблицы table1 как имело тип type1, так его и имеет. Изменились свойства типа type1 (а именно его имя). Об этом Аксапта честно и сообщит. Ничего пропущено не будет.
4. Если для Вас эта проблема критична, есть два пути: админситративный и технологический. Для того, чтобы пойти по первому пути, запретите удаление объектов в своем приложении. Вместо этого добавляйте им префикс DEL_ и ставьте конфигурационный ключ (где можно) SysDeletedObjects* (можете создать свой ключ для таких целей). Второй путь - напишите собственную функцию сравнения объектов, которая будет раскапывать источник различий.
5. AOTGetProperties возвращает обработанную информацию. Учитывайте, что для поля таблицы не Аксапта не хранит название типа. Хранится только номер. AOTGetProperties этот номер преобразует в имя. При этом используется текущее окружение, а не Old. Опять же, если Вас это не устраивает, это еще не доказательство того, что это криво. В конце концов, что Вам мешает сделать расширенную версию AOTGetProperties, которая будет работать так, как Вам нравится?

[db]

Как хотите Все, замолкаю и никого (бесплатно) переубеждать не собираюсь.

А насчет если дизайн не нравится, то и х с ним, это не мой подход. Ибо это не решает проблем, а плодит заплатки, потом заплатки к заплаткам и т.д.

За последний год MS собрал по моим запросам 8 штук private hot fix для ядра аксапты. Проблемы желательно решать, а не прилаживаться к ним. Ибо только заняв активную позицию мы содействуем повышению качества аксапты

Все, всем успехов

[Torin]

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

[uchenik]

Цитата:

Сообщение от Maxim Gorbunov

4. Если для Вас эта проблема критична, есть два пути: админситративный и технологический. Для того, чтобы пойти по первому пути, запретите удаление объектов в своем приложении. Вместо этого добавляйте им префикс DEL_ и ставьте конфигурационный ключ (где можно) SysDeletedObjects* (можете создать свой ключ для таких целей).

Свой ключ создать можно, но система при этом все равно подругивается, что ключ не тот.

[konopello]

Может не в тему, но вставлю и я свои пару копеек про Терминальные сессии.

Второй год работаю, только используя Терминальную сессию на серверах в германии, одновременно со мной работают американские коллеги, индийские, китайские, сингапур, и т.д. Проблем нет, нет ни каких объединений. (правда это сап, специально маленькими буквами дабы не выделятся), вот однако есть одна хитрость:

Ландшафт состоит из: система долгосрочной разработки (все что новое и занимает больше пол года) --> система долгосрочного тестирования --> разработка --> тестовая система --> продакшан {после отправки в продакшен, происходит синхронизация с долгосрочными системами, из долгосрочных систем транспорты в обычный ландшафт уходят ежемесячно }.

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


вот......

если не в тему удалите пост, спс