| Альтернативная система контроля версий. |
Как известно, подавляющее большинство языков программирования
формализованы, т.е. известна и конечна их синтаксическая структура.
Это постулат первый.
Большинство систем контроля версий работает с файлами, как наименьшим
элементом обмена информацией. То есть, в ряде систем используемый файл лочится
(недоступен другим разработчикам) или создаются его редакции, которые
затем сливаются (merging), что тоже часто вызывает коллизии
неразрешимые автоматическими средствами. Это постулат воторой.
Язык разметки XML хорошо подходит для хранения структурированной
информации и обмена ей. Это замечание.
Предположение: возможно сделать такую систему контроля версий, которая
работает со структурными элементами языка, как наименьшими единицами
обмена информацией. То есть, если вам нужно отредактировать один метод
класса в модуле, то лочится для других пользователей системы только
этот метод. После редактирования метод мержуется на основе
синтаксической структуры класса, а не на основе построчного сравнения
редакций файла.
Александр Бакулин
Всего в теме 44 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Case-средства, средства коллективной разработки и т.п.
- О CASE средствах.
- Системы контроля версий.
- Change Manager DS
- О системах контроля ошибок
- Системы контроля версий. Средства управления проектом.
| № 24 20-04-2004 18:01 |   |
Ответ на »сообщение 23« (Сергей Тарасов)
___________________________
Она успешно решается соблюдением правила "вечером сохранить в репозитории все изменения за день".
___________________________
Это тоже не метод. Если я приду на работу раньше других и соберу билд с сохраненными вчера вечером, но нерабочими изменениями? Это, мягко говоря, нехорошо будет. Если уж забираем модуль на редактирование, то до тех пор, пока не закончим (а лучше и оттестируем) изменения. А на случай болезни и т.д. соответствующие права должны быть у администратора. Все вполне решаемо.
| № 23 20-04-2004 15:12 | |
Ответ на »сообщение 21« (Jack Of Shadows)
___________________________
Ответ на »сообщение 17« (Сергей Перовский)
___________________________
Однако это перл уважаемый ! Вам кило клюквы. :))
А что если автор умер ? Файлы навечно останутся залоченными ?
А если он в отпуск ушел, а надо срочно добавить, исправить, изменить что нибудь ?
Это не столь большая проблема, как может показаться.
Она успешно решается соблюдением правила "вечером сохранить в репозитории все изменения за день".
Дополнительное рекомендуемое требование: одинаковая стандартизованная среда/окружение на всех ПК разработчиков группы.
| № 22 20-04-2004 10:29 | |
Ответ на »сообщение 20« (Дмитрий Пашин)
___________________________
Но проблемы, описанные в пункте 1 - это проблемы нотификации. Программисты должны работать с ситемой оповещения о таких изменениях.
Систему оповещения - в студию! Таких систем я ни разу не встречал, и, боюсь, встречу еще не скоро..
Даже разработка правил такой нотификации - очень нетривиальная задача.
_____________________________________
Простейшая система нотификации - разослать письма всему коллективу разработчиков об изменениях в коде. А так любая система управления проектом должна это поддерживать. Есть, например, AQDevTeam. Строим дерево проекта, для каждого модуля создаем свою ветвь. При каждом изменении модуля добавляем заметку с описанием изменений, если они затрагивают межмодульное\межклассовое взаимодействие. А уже на это событие можно или почту разослать всем заинтересованным или каким-либо другим способом оповестить.
| № 21 20-04-2004 07:35 | |
Ответ на »сообщение 17« (Сергей Перовский)
___________________________
Однако это перл уважаемый ! Вам кило клюквы. :))
А что если автор умер ? Файлы навечно останутся залоченными ?
А если он в отпуск ушел, а надо срочно добавить, исправить, изменить что нибудь ?
| № 20 20-04-2004 06:53 | |
Ответ на »сообщение 11« (Александр)
___________________________
Но проблемы, описанные в пункте 1 - это проблемы нотификации. Программисты должны работать с ситемой оповещения о таких изменениях.
Систему оповещения - в студию! Таких систем я ни разу не встречал, и, боюсь, встречу еще не скоро..
Даже разработка правил такой нотификации - очень нетривиальная задача.
_____________________________________
Ответ на »сообщение 19« (Виктор)
___________________________
Я предлагаю разбить понятие файл до Единици. И уже Единицы строить в деревья. Где каждая ветвь будет отвечать за определенные действия программы.
Если я верно понял мысль, это очень похоже на определение компилятора/интерпретатора :)
Чтобы эту альтернативную CVS можно было использовать для распознавания конфликтов на уровне языка программирования(я не говорю уже даже об автоматическом объединении), нужно, чтобы она работал АБСОЛЮТНО так же, как и родной компилятор.
Представим себе объем работы по написанию компилятора, абсолютно идентичного Borland Delphi :)
| № 19 19-04-2004 20:00 | |
Ответ на »сообщение 15« (Александр)
___________________________
Ответ на »сообщение 14« (Max Belugin)
___________________________
Видимо да, но не слишком ли это усложнит задачу? Каждый раз файл склеивать и разрезать...
А зачем, склеивать и разрезать. Построение программы происходит на основе Единиц.
Все абсолютно навороты типа Классов, объектов ActiveX, СOM, DCOM ... служат основном для облегчение жизни Человека. Но не компьютера. Компьютер понимает только нули и единици.
Вы понимаете понятие файл только как совокупность Единиц отвечающих за определенные действия программы. Я предлагаю разбить понятие файл до Единици. И уже Единицы строить в деревья. Где каждая ветвь будет отвечать за определенные действия программы.
| № 18 19-04-2004 15:57 | |
| № 17 19-04-2004 15:20 | |
Большинство проблем, для решения которых создавались системы совместной разработки, возникло от неграмотной организации работ.
Зачем "лочить" файлы (или методы), если у каждого файла есть АВТОР и никто, кроме него НЕ ИМЕЕТ ПРАВА вносить какие либо изменения.
На основании своего опыта могу утверждать, что необходимость исправить чужой код означает только неумение архитектора проекта правильно расчленить задачу и неумение руководителя проекта наладить взаимодействие разработчиков.
| № 16 19-04-2004 14:06 | |
Ответ на »сообщение 13« (Виктор)
___________________________
Мое мнение, что для разработки чего-то подобного потребутеся оченьмного сил. А доходы для программистов весьма малы и они врядли откажутся от текущего стандарта. А наличие большого количества языков в одном проекте, во-первых к расползанию проекта, и во-вторых к увелчению его размера, поскольку каждый язык будет тащить свой набор библиотек, если вы конечно не имеете ввиду сборку в DLL, но здесь есть свои проблемы. В общем то мое мнение, что проект будет очень убыточным.
При определнной организации процесса разработки, можно избежать этих проблем почти на 100 процентов.
А во время рефакторинга, нельзя лочить один метод, поскольку он часто перемещается по иерархии класов. Так, что во время рефакторинга необходимо блокировать модуль и все модули с ним связанные целиком, чтобы потом не было сюрпризов, ИМХО.
| № 15 19-04-2004 12:55 | |
Ответ на »сообщение 14« (Max Belugin)
___________________________
если сделать нечто, что представляет структурные единицы программы, как тектовые файлы, это решит проблему?
Видимо да, но не слишком ли это усложнит задачу? Каждый раз файл склеивать и разрезать... По идее да, данную идею можно свести к существующим средствам контроля версий таким путем. Вопрос - проще ли этот путь?
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
