Альтернативная система контроля версий. |
Как известно, подавляющее большинство языков программирования
формализованы, т.е. известна и конечна их синтаксическая структура.
Это постулат первый.
Большинство систем контроля версий работает с файлами, как наименьшим
элементом обмена информацией. То есть, в ряде систем используемый файл лочится
(недоступен другим разработчикам) или создаются его редакции, которые
затем сливаются (merging), что тоже часто вызывает коллизии
неразрешимые автоматическими средствами. Это постулат воторой.
Язык разметки XML хорошо подходит для хранения структурированной
информации и обмена ей. Это замечание.
Предположение: возможно сделать такую систему контроля версий, которая
работает со структурными элементами языка, как наименьшими единицами
обмена информацией. То есть, если вам нужно отредактировать один метод
класса в модуле, то лочится для других пользователей системы только
этот метод. После редактирования метод мержуется на основе
синтаксической структуры класса, а не на основе построчного сравнения
редакций файла.
Александр Бакулин
Всего в теме 44 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Case-средства, средства коллективной разработки и т.п.
- О CASE средствах.
- Системы контроля версий.
- Change Manager DS
- О системах контроля ошибок
- Системы контроля версий. Средства управления проектом.
<<<... | 34—25 | 24—15 | ...>>> Всего сообщений в теме: 44; страниц: 5; текущая страница: 2
№ 34 23-04-2004 09:20 |  |
№ 33 23-04-2004 06:43 |  |
Ответ на »сообщение 31« (Сергей Тарасов)
Второй пилот - это из Брукса, про операционнную бригаду. Антипод ХР, тсзать.
Извиняюсь за флуд, но можно все-то подробнее для малоначитанных (либо, что еще лучше, ссылку кинуть), что за Брукс, что за пилот....
№ 32 23-04-2004 04:20 |  |
Ответ на »сообщение 31« (Сергей Тарасов)
___________________________
А в чем здесь проблема
Так в том то и дело что проблем никаких нет.
Какая разница кто автор файла ? Не один так другой пусть работает.
А вот Перовский говорит - нет. Только автор мол пусть и работает с файлом а больше никто. А если кто то еще, то тогда ты плохой архитектор.
Вот мне и интересно, что это за второй пилот, который вроде бы и не автор, но в то же время ему Перовский видимо разрешает работать с чужими файлами. Правда почему тогда не всем в команде - непонятно.
№ 31 22-04-2004 21:46 |  |
Ответ на »сообщение 30« (Jack Of Shadows)
___________________________
Так я пример такой ситуации привел - "умер, уехал, уволился".
Так что очередь за вами. Колитесь, что это за второй пилот такой ?
А в чем здесь проблема, если тот, кто "умер, уехал, уволился" ежедневно вечером сохраняет результаты своего труда в репозитории ?
Максимум потерь - 1 день работы специалиста.
Второй пилот - это из Брукса, про операционнную бригаду. Антипод ХР, тсзать.
№ 30 22-04-2004 20:18 |  |
Ответ на »сообщение 28« (Сергей Перовский)
___________________________
По поводу "умер, уехал, уволился" - это работа руководителя проекта. Есть идеология "второго пилота" и т.п.
Поясните пожалуйста. Что за идеология второго пилота ?
Приведите, пожалуйста, пример ситуации, при которой НЕОБХОДИМА одновременная работа программистов над одним модулем.
В системах где взятый на редактирование файл закрывается, одновременная работа невозможна.
Вы наверное имели ввиду работа нескольких программистов с одним модулем (неодновременная)
Так я пример такой ситуации привел - "умер, уехал, уволился".
Так что очередь за вами. Колитесь, что это за второй пилот такой ?
№ 29 22-04-2004 19:27 |  |
Берите все проше (Take it easy). Одно из первых правил, которых я выучил на зубок при программировании.
Если очень долго долбишся головой об стену, потому что не можеш найти выход из проблемы которая возникла при решении задачи, то придумай решение которое принципиально не содержит эту проблему. И все получится.
Пример. Как-то я столкнулся с решением задачи больших чисел. Также нужно было производить сортировку больших массивов больших чисел.
Тот что встроен в компилятор (Delphi, C++) сортировшик при массиве более 1000 элементов вылетал причем стабильно. После этого я понял поговорку - "Рекурсия это метод программирования богов" потому что только у богов есть компьютеры с очень большим (бесконечным) стеком. На одном из форумов наткнулся на название "Битовый сортировшик". В литературе по алгоритмам я его не нашел. Пришлось придумывать. Работает стабильно. Миллион элементов по 32 байта сортирует на 850 целероне за 20 с.
№ 28 22-04-2004 14:37 |  |
Ответ на »сообщение 25« (Jack Of Shadows)
___________________________
По поводу "умер, уехал, уволился" - это работа руководителя проекта. Есть идеология "второго пилота" и т.п.
Но в общем Вы поняли меня абсолютно точно. Если над файлом приходится работать нескольким программистом, значит архитектор неквалифицированный.
Приведите, пожалуйста, пример ситуации, при которой НЕОБХОДИМА одновременная работа программистов над одним модулем.
Я считаю, что "системы совместной разработки" в их современном виде порождены заблуждением, что автоматизация сглаживает проблемы организации, тогда как она их усиливает.
Нельзя автоматизировать беспорядок.
№ 27 21-04-2004 10:31 |  |
Ответ на »сообщение 26« (Дмитрий Пашин)
___________________________
Ответ на »сообщение 22« (Александр)
Кто должен добавлять заметку о том, что изменения затрагивают межмодульное/межклассовое взаимодействие? Если человек, то чем эта альтернативная CVS будет отличаться от существующих?
Если программа, то каким образом она будет эта делать (подводные камни см. в »сообщение 6«) и каковы будут правила этой нотификации?
Ну, автоматизировать часть этой работы можно. Например, при изменении числа и вида параметров в методе/функции. При удалении функции, при изменении области видимости метода, при добавлении нового. Это отследить можно (для каждого конкретного языка). Вполне допускаю, что есть изменения, которые автоматически отследить нельзя - изменение логики работы и т.п. Это уже ляжет на плечи человека.
Я и не расчитывал предложить панацею, просто хотелось свежим сторонним взглядом оценить идею.
№ 26 21-04-2004 05:09 |  |
Ответ на »сообщение 22« (Александр)
Простейшая система нотификации - разослать письма всему коллективу разработчиков об изменениях в коде <...> При каждом изменении модуля добавляем заметку с описанием изменений, если они затрагивают межмодульное\межклассовое взаимодействие
Вы абсолютно правы, нотификация об изменениях модулей есть практически более-менее продвинутых CVS. Но я то хотел обратить внимание на другое: Кто должен добавлять заметку о том, что изменения затрагивают межмодульное/межклассовое взаимодействие? Если человек, то чем эта альтернативная CVS будет отличаться от существующих?
Если программа, то каким образом она будет эта делать (подводные камни см. в »сообщение 6«) и каковы будут правила этой нотификации?
№ 25 20-04-2004 21:08 |  |
Ответ на »сообщение 23« (Сергей Тарасов)
___________________________
Она успешно решается соблюдением правила "вечером сохранить в репозитории все изменения за день".
Сергей, почитайте внимательно что предлагает Перовский. Сохраняй не сохраняй, а изменять файл может только автор.
Более того, дальше он пишет.
На основании своего опыта могу утверждать, что необходимость исправить чужой код означает только неумение архитектора проекта правильно расчленить задачу и неумение руководителя проекта наладить взаимодействие разработчиков
Т.е. сохраняй, не сохраняй, но если у тебя один человек создал файл, а другой потом его изменил, значит ты хреновый архитектор :)))
<<<... | 34—25 | 24—15 | ...>>> Всего сообщений в теме: 44; страниц: 5; текущая страница: 2
Добавить свое сообщение
Отслеживать это обсуждение 
Дополнительная навигация: |
|