Было дело, работал я в софтверной компании, ориентированной на госзаказы. И писали они (до сих пор пишут) на Visual FoxPro (VFP). Единственная причина, которая удерживала меня там — это деньги. В остальном ситуация напоминала ёжиков, грызущих кактусы.
Согласно политике компании автоматизация разработки должна опираться на бесплатные системы, поэтому в качестве системы управления проектами был выбран Trac, соответственно, система управления версиями — SVN. Но в результате внедрения возникли небольшие затруднения.
В VFP есть такие типы файлов:
• *.SCX/*.SCT (зависимая пара файлов, описывающая одну форму)
• *.VCX/*.VCT (зависимая пара файлов, описывающая одну библиотеку классов).
Эти типы по своей сути представляют DBF со спецполями, некоторые из которых не документированы. Т.е. для SVN это просто бинарные файлы. Если кто-то менял класс в библиотеке VCX, то все остальные ждали коммита, ибо операция слияния для бинарных файлов обламывалась. По той же причине не работала операция сравнения, в результате между SVN-сервером и клиентом TortoiseSVN гонялись бинарные файлы в полном объёме.
Не долго думая, решили на-лету конвертировать их в текстовый формат, благо в Интернете нашли генератор (ftp://ftp.prolib.de/public/vfp/pl_scctext.prg). Я был немало удивлён, когда узнал, что патриоты VFP создали на базе него свой генератор Alternate SCCText (http://www.codeplex.com/VFPX/Release/ProjectReleases.aspx?ReleaseId=12955). И это в ноябре 2008 года! К сожалению, утилита SCCText.prg работала только в одну сторону, т.е. из текста получить обратно SCX или VCX было нельзя.
Мы пошли другим путём. Использовали проект TwoFox (http://www.foxpert.com/docs/cvs.en.htm), который преобразовывал в обе стороны без потерь, при чём создавал XML из VCX/SCX и наоборот, из XML формировал VCX/SCX. Оставалось сделать так, чтобы конвертирование производилось на лету, т.е. мы хотели, чтобы на SVN-сервере хранились XML, а сам FoxPro подхватывал уже VCX/SCX.
Поставили на каждое клиентское место nnCron (менеджер автоматизации) и nnBackup (утилита резервного копирования, умеющая создавать и обрабатывать файл-листы) (http://www.nncron.ru/index_ru.shtml). При изменении папки проекта (при сохранении файла из среды программирования VFP, или в результате операции Update из SVN), а также по таймаутам планировщик nnCron натравливал на папку проекта утилиту nnBackup, которая строила файл-лист проекта. Сравнивая новый файл-лист со старым, мы определяли, какие собственно файлы проекта необходимо конвертировать.
Далее, к TortoiseSVN была прикручена утилита сравнения XML (тогда мы использовали Altova DiffDog) и всё заработало как часы.
Согласно политике компании автоматизация разработки должна опираться на бесплатные системы, поэтому в качестве системы управления проектами был выбран Trac, соответственно, система управления версиями — SVN. Но в результате внедрения возникли небольшие затруднения.
В VFP есть такие типы файлов:
• *.SCX/*.SCT (зависимая пара файлов, описывающая одну форму)
• *.VCX/*.VCT (зависимая пара файлов, описывающая одну библиотеку классов).
Эти типы по своей сути представляют DBF со спецполями, некоторые из которых не документированы. Т.е. для SVN это просто бинарные файлы. Если кто-то менял класс в библиотеке VCX, то все остальные ждали коммита, ибо операция слияния для бинарных файлов обламывалась. По той же причине не работала операция сравнения, в результате между SVN-сервером и клиентом TortoiseSVN гонялись бинарные файлы в полном объёме.
Не долго думая, решили на-лету конвертировать их в текстовый формат, благо в Интернете нашли генератор (ftp://ftp.prolib.de/public/vfp/pl_scctext.prg). Я был немало удивлён, когда узнал, что патриоты VFP создали на базе него свой генератор Alternate SCCText (http://www.codeplex.com/VFPX/Release/ProjectReleases.aspx?ReleaseId=12955). И это в ноябре 2008 года! К сожалению, утилита SCCText.prg работала только в одну сторону, т.е. из текста получить обратно SCX или VCX было нельзя.
Мы пошли другим путём. Использовали проект TwoFox (http://www.foxpert.com/docs/cvs.en.htm), который преобразовывал в обе стороны без потерь, при чём создавал XML из VCX/SCX и наоборот, из XML формировал VCX/SCX. Оставалось сделать так, чтобы конвертирование производилось на лету, т.е. мы хотели, чтобы на SVN-сервере хранились XML, а сам FoxPro подхватывал уже VCX/SCX.
Поставили на каждое клиентское место nnCron (менеджер автоматизации) и nnBackup (утилита резервного копирования, умеющая создавать и обрабатывать файл-листы) (http://www.nncron.ru/index_ru.shtml). При изменении папки проекта (при сохранении файла из среды программирования VFP, или в результате операции Update из SVN), а также по таймаутам планировщик nnCron натравливал на папку проекта утилиту nnBackup, которая строила файл-лист проекта. Сравнивая новый файл-лист со старым, мы определяли, какие собственно файлы проекта необходимо конвертировать.
Далее, к TortoiseSVN была прикручена утилита сравнения XML (тогда мы использовали Altova DiffDog) и всё заработало как часы.