если сделать нечто, что представляет структурные единицы программы, как тектовые файлы, это решит проблему?

Я полностью согласен с автором вопроса. Нужно чтоб контроль версионности проходил не на уровне файла, а на более низком уровне. На уровне глобальных процедур, обьектов, структур, переменных. К этому можно добавить, что в этой системе я бы предусмотрел отдельную компиляцию всех процедур на машине программиста. С последующим тестированием по входным и выходным параметрам.
На центральном сервере каждая глобальная процедура, обьект, переменная и структура регистрируется. И сразу становится видной для всех пользователей этой системы. При этом Сервер будет хранить не только конечную (рабочую) версию данной единицы но и все придедущие. И только тот человек, который создал данную единицу может в последствии редактировать ее.
Любое сеанс редактирования единицы вызывает повышение версии данной единицы. И только человек ответственный за данную единицу будет устанавливать номер рабочей версии данной единицы.
Все локальные единицы не будут видны для всех остальных пользователей. Но при этом я думаю, что также нужен контроль версионности. только сервером версионности будет выступать локальная машина.
На сервер версий будут сливаться уже откомпилированные единицы плюс исходный код.
Серверу только останется соединить все модули в соответсвии со своей таблицей единиц.
Также я думаю, что он будет распределять эти единицы по файлам библиотек, если они будут предусмотрены.
Будет фактически не важно на каком языке программирования будут писаться каждая единица в отдельности. Самое главное чтоб соблюдался единный формат всех конечных модулей.

Сейчас обычно синхронизируют на уровне элементов, "известных" операционной системе (именно там и сетевые средства). Я думаю такую систему можно придумать и встроить в какоую-нибудь RAD. В любом случае, пока у нас ОСи не будут знать "нечто отличное" от файлов, для "общего решения" силы тратить не стОит...

Ответ на »сообщение 10« (Max)
___________________________


Почему-то »сообщение 6« Александр "не заметил" :(


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

Ответ на »сообщение 6« (Дмитрий Пашин)
___________________________

Пример 1. программист A изменил в родительском классе объявление метода(в наследниках о не использовался), а программист B в это же время добавил в классе-наследнике вызов этого метода по старому объявлению.


Поддерживаю, вне зависимости от метода блокировки в VCS будет нерабочий код :(

Почему-то »сообщение 6« Александр "не заметил" :(

Ответ на »сообщение 8« (Max Belugin)
___________________________


А работа без блокирования вам не нравится?

Не то чтобы не нравится, но она не вызовет коллизий. К тому же, если один метод одновременно правят два человека это недостаток либо архитектуры, либо управления проектом.

Ответ на »сообщение 7« (Александр)
___________________________


На уровне методов применяется блокирование. То есть одонвременно один метод 2 челоека изменять не могут. Соответственно и проблем вроде бы должно быть меньше и работать с файлом могут несколько человек. Но это мое IMHO.

А работа без блокирования вам не нравится?

Ответ на »сообщение 5« (Max Belugin)
___________________________

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

На уровне методов применяется блокирование. То есть одонвременно один метод 2 челоека изменять не могут. Соответственно и проблем вроде бы должно быть меньше и работать с файлом могут несколько человек. Но это мое IMHO.

Подобная идея у меня уже возникала, и вот к каким выводам я пришел:

Хороший стиль проектирования - сильная связность методов внутри модуля и слабое сцепление между модулями (см., например, Орлов С.А. Технологии разработки программного обеспеченияю СПб.: Питер, 2002).
Поэтому одновременная переработка разными программистами одного и того же модуля очень часто приводит к конфликтам, которые разобрать  автоматически с помощью синтаксического анализа программы невозможно.

Пример 1. программист A изменил в родительском классе объявление метода(в наследниках о не использовался), а программист B в это же время добавил в классе-наследнике вызов этого метода по старому объявлению.
Пример 2. директивы компиляции

Даже копиляторы могут лишь обнаружить такие конфликты, а объединить их со 100%ной правильностью может пока лишь человек.
Мораль: Синтаксический анализ программ будет не намного лучше построчного сравнения.
Я бы тратить силы на разработку такого ПО не стал...

Ответ на »сообщение 3« (Max Belugin)
___________________________
Да, приходилось использовать и SourceSave, и CVS. Именно в CVS в некоторых случаях и получаются проблемы при мержевании версий, которые невозможно разрешить автоматически.

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