Всем привет. Собственно, вопрос аналогичен тому, что поднимался в ветке http://gzip.rsdn.ru/forum/message/3078280.aspx

Автор: _DeKa_
Дата: 26.08.08

, но относительно TFS'а.
Вкратце — имеется несколько проектов, которые используются различные версии внешних библиотек:

root
  Externals
    Lib1
      V1
      V2
    Lib2
      V1
      V2
  App1 (uses Lib1::v1, Lib2::v2)
  App2 (uses Lib1::v2, Lib2::v1)

Хочется дать возможность разработчику получать каждый проект (AppN) единым "кирпичем", дабы не иметь проблем с версионностью. Пытаюсь вот понять, какие есть возможности решения этой проблемы в рамках TFS, и ничего, кроме ручного копирования соотв. библиотек, либо жесткого зашития версий в проекты (указанием в инклюдах либо переменными окружения) не вижу.
Вообще, хочется, чтобы в результате для каждого приложения у разработчика формировалось нечто вроде следующей структуры каталогов:

  App1 (uses Lib1::v1, Lib2::v2)
    Externals
      Lib1
        V2
      Lib2
        V1

либо как-то еще, дабы не морочится с настройками проектов, а использовать относительные пути.

Может, есть какой-то разумный подход, позволяющий решить указанную проблему в рамках TFS?

Заранее спасибо!

Здравствуйте, Andrew S, Вы писали:

AS>Вкратце — имеется несколько проектов, которые используются различные версии внешних библиотек:

В TFS очень хорошее API. Поэтому можно написать небольшую утилитку, которая сформирует рабочее место программиста (например на основе XML файла, который лежит в TFS под Source Control). Она счтитает из TFS XML файл настройки для каждого проекта, создаст каталоги, создаст Workspace. Весь процесс настройки рабочего места может быть автоматизирован — и ничего не придется делать вручную.

AS>>Вкратце — имеется несколько проектов, которые используются различные версии внешних библиотек:

VV>В TFS очень хорошее API. Поэтому можно написать небольшую утилитку, которая сформирует рабочее место программиста (например на основе XML файла, который лежит в TFS под Source Control). Она счтитает из TFS XML файл настройки для каждого проекта, создаст каталоги, создаст Workspace. Весь процесс настройки рабочего места может быть автоматизирован — и ничего не придется делать вручную.

Ну, зачем же так переусложнять. Все уже придумано за нас Например, можно использовать бранчи. Как именно — на www.codeplex.com . Имхо, там предлагается очень вменяемая структура каталогов и способы управления проектом.

Здравствуйте, Andrew S, Вы писали:

AS>Ну, зачем же так переусложнять. Все уже придумано за нас Например, можно использовать бранчи. Как именно — на www.codeplex.com . Имхо, там предлагается очень вменяемая структура каталогов и способы управления проектом.

Мы используем бранчи + автоматический маппинг каталогов скриптом. Я отвечал на вопрос "Хочется дать возможность разработчику получать каждый проект (AppN) единым "кирпичем" и на "Вообще, хочется, чтобы в результате для каждого приложения у разработчика формировалось нечто вроде следующей структуры каталогов" — что у нас и происходит при запуске мини-приложения на компьютере программиста (не каждый день конечно — а один раз при настройке рабочего места). При этом автоматически создается структура каталогов похожая на вашу и используются относительные пути в настройках проектов.

AS>>Ну, зачем же так переусложнять. Все уже придумано за нас Например, можно использовать бранчи. Как именно — на www.codeplex.com . Имхо, там предлагается очень вменяемая структура каталогов и способы управления проектом.

VV>Мы используем бранчи + автоматический маппинг каталогов скриптом. Я отвечал на вопрос "Хочется дать возможность разработчику получать каждый проект (AppN) единым "кирпичем" и на "Вообще, хочется, чтобы в результате для каждого приложения у разработчика формировалось нечто вроде следующей структуры каталогов" — что у нас и происходит при запуске мини-приложения на компьютере программиста (не каждый день конечно — а один раз при настройке рабочего места). При этом автоматически создается структура каталогов похожая на вашу и используются относительные пути в настройках проектов.

Ясно, спасибо. А в чем смысл маппинга, если использовать относительные пути и сохранять относительное положение в репозитории и локально? В смысле, это как раз и есть "одним кирпичем". Т.е. коммоны и внешние либы натасканы в нужную структуру каждого проекта бранчами. А с использованием схемы каталогов, предложенной на codeplex, это все зеркально отражается на локальную структуру разработчика... В общем, мы так сделали, пока что нравится — довольно просто версионироваться и обновляться. Да и в целом очень просто получается, сложно ошибку допустить, все, как и сказано на codeplex, "explicit".

Да, кстати, как вообще впечатления от TFS? У меня пока что очень неоднозначные... Имхо, довольно бедный репозиторий (по сравнению, например, с SVN), довольно убогая система билда, а про workflow и говорить не приходится — очень примитивно все... Вроде все вместе оно как-то работает, но сколько гимора при малейшем шаге вправо-влево. Честно говоря, создается ощущение довольно сырого продукта . Хотя, конечно, это смотря как использовать — я смотрю, на codeplex народ неплохо освоился

Здравствуйте, Andrew S, Вы писали:

AS>Ясно, спасибо. А в чем смысл маппинга, если использовать относительные пути и сохранять относительное положение в репозитории и локально?

У нас структура каталогов в репозитарии и локально немного отличается. Это сделано для удобства поддержки разных версий. Если делать бранчами — то приходится делать лишние телодвижения для исправления ошибок — нужно исправить ошибку в библиотеке и замерджить исправление во все проекты, которые пользуются бранчем этой библиотеки. Может это конечно и "much more explicit", но у нас цена случайно не замерджить исправления в какой-либо проект выше "гибкости" этого подхода (да и утомительно это). Мы от него отказались — у нас много проектов и часто бывают изменения в библиотеках, которые должны быть применены во все проекты, где эти библиотеки используются. Вобщем это просто другой подход (тоже описанный на codeplex).


AS>Да, кстати, как вообще впечатления от TFS? У меня пока что очень неоднозначные...

Ну не стоит забывать, что это все-таки первая/вторая версия продукта — функционала кое-где не хватает конечно — но ядро заложено очень мощное и API удобное. Продукт на месте не стоит, например, во второй версии TFSBuild получше чем был ранее, да и другие фичи добавились. Посмотрите сколько к нему уже плагинов понаписано — это говорит об удобстве программирования под него. TFS очень настраиваемая система — но плата за это — высокий порог входа (естественно для нетривиальных вещей). У нас фирма специализируется на разработке продуктов под Windows и нужно было интегрированное решение для управления процессом разработки — мы выбрали TFS, выделили спец человека, который занимается его настройкой. Если компания не маленькая и специализируется на MS — это нормальное решение с прицелом на будущее. Для маленьких компаний и компаний, которые не используют продукты MS, есть другие решения, в чем-то уступающие, в чем-то превосходящие TFS (кстати у SVN пока нет истории мерджей). В других интегрированных системах такая же ситуация — когда надо сделать не "как у всех" приходится много допиливать. Самое грустное это конечно цена .

Здравствуйте, Voyachek Vladislav, Вы писали:

VV>(кстати у SVN пока нет истории мерджей).
http://subversion.tigris.org/svn_1.5_releasenotes.html#merge-tracking Ы?

Здравствуйте, Voyachek Vladislav, Вы писали:

[]

VV>Ну не стоит забывать, что это все-таки первая/вторая версия продукта — функционала кое-где не хватает конечно — но ядро заложено очень мощное и API удобное. Продукт на месте не стоит, например, во второй версии TFSBuild получше чем был ранее, да и другие фичи добавились. Посмотрите сколько к нему уже плагинов понаписано — это говорит об удобстве программирования под него. TFS очень настраиваемая система — но плата за это — высокий порог входа (естественно для нетривиальных вещей). У нас фирма специализируется на разработке продуктов под Windows и нужно было интегрированное решение для управления процессом разработки — мы выбрали TFS, выделили спец человека, который занимается его настройкой. Если компания не маленькая и специализируется на MS — это нормальное решение с прицелом на будущее. Для маленьких компаний и компаний, которые не используют продукты MS, есть другие решения, в чем-то уступающие, в чем-то превосходящие TFS (кстати у SVN пока нет истории мерджей). В других интегрированных системах такая же ситуация — когда надо сделать не "как у всех" приходится много допиливать. Самое грустное это конечно цена .

Не знаю чего у них там нет, но svn не мешает работе, чего не скажешь про это убожество tfs.

AS>>Ясно, спасибо. А в чем смысл маппинга, если использовать относительные пути и сохранять относительное положение в репозитории и локально?

VV>У нас структура каталогов в репозитарии и локально немного отличается. Это сделано для удобства поддержки разных версий. Если делать бранчами — то приходится делать лишние телодвижения для исправления ошибок — нужно исправить ошибку в библиотеке и замерджить исправление во все проекты, которые пользуются бранчем этой библиотеки. Может это конечно и "much more explicit", но у нас цена случайно не замерджить исправления в какой-либо проект выше "гибкости" этого подхода (да и утомительно это). Мы от него отказались — у нас много проектов и часто бывают изменения в библиотеках, которые должны быть применены во все проекты, где эти библиотеки используются. Вобщем это просто другой подход (тоже описанный на codeplex).

Можно и наоборот — исправил ошибку в бранче, замержил в коммон, потом — обратно. Зато не ошибешься, и раздашь каждому то, что надо...

В общем, ок, спасибо за ответы Будет дальше пока что мучиться, но перфорс мне все-равно больше нравится, вот хоть убейте меня Если бы не начальство...эхх.

AS>Хочется дать возможность разработчику получать каждый проект (AppN) единым "кирпичем", дабы не иметь проблем с версионностью. Пытаюсь вот понять, какие есть возможности решения этой проблемы в рамках TFS, и ничего, кроме ручного копирования соотв. библиотек, либо жесткого зашития версий в проекты (указанием в инклюдах либо переменными окружения) не вижу.

В DotNet есть замечательная вещью Называется GAC с его байндингами версий.
Или просто настройки байндинга версий в конфигурации проекта (настройка декларативно аналогична настройкам GAC в machine.config)
Есть ещё файлы policy (для более извращённого конфигурирования).
И не надо никуда библиотеки таскать.

AS>>Хочется дать возможность разработчику получать каждый проект (AppN) единым "кирпичем", дабы не иметь проблем с версионностью. Пытаюсь вот понять, какие есть возможности решения этой проблемы в рамках TFS, и ничего, кроме ручного копирования соотв. библиотек, либо жесткого зашития версий в проекты (указанием в инклюдах либо переменными окружения) не вижу.

VGn>В DotNet есть замечательная вещью Называется GAC с его байндингами версий.
VGn>Или просто настройки байндинга версий в конфигурации проекта (настройка декларативно аналогична настройкам GAC в machine.config)
VGn>Есть ещё файлы policy (для более извращённого конфигурирования).
VGn>И не надо никуда библиотеки таскать.

И какое это отношение имеет к разработке вообще и к контролю версий в частности? В общем, не стоит думать, что .нет это решение всех проблем .

AS>И какое это отношение имеет к разработке вообще и к контролю версий в частности? В общем, не стоит думать, что .нет это решение всех проблем .

Это имеет отношение к контролю версий (точнее конфигураций) при разработке на дотнет.
Если вы разрабатываете на плюсах, то озвученная проблема должно быть не единственная из проблем вашей версионности. Сочувствую.
Если же вы используете TFS вообще в отрыве от мелкосовтовской IDE, то вы извращенцы.

Здравствуйте, VGn, Вы писали:

VGn>В DotNet есть замечательная вещью Называется GAC
Каким образом GAC поможет решить проблему с хранением нескольких версий одной сборки в TFS?

AS>>И какое это отношение имеет к разработке вообще и к контролю версий в частности? В общем, не стоит думать, что .нет это решение всех проблем .

VGn>Это имеет отношение к контролю версий (точнее конфигураций) при разработке на дотнет.

Это называется не контроль версий, а контроль модулей. К разработке в смысле менеджмента исходного кода это отношения не имеет вообще.

VGn>Если вы разрабатываете на плюсах, то озвученная проблема должно быть не единственная из проблем вашей версионности. Сочувствую.

Вы не в курсе. Сочуствую

VGn>Если же вы используете TFS вообще в отрыве от мелкосовтовской IDE, то вы извращенцы.

Но комментс. В игнор.

VGn>>В DotNet есть замечательная вещью Называется GAC
O>Каким образом GAC поможет решить проблему с хранением нескольких версий одной сборки в TFS?

Не нужно хранить уже скомпиленные сборки в TFS. Контроль версий бинарников — это уже контроль конфигураций. Контроль конфигураций относительно библиотек может быть осуществим уже перечисленными мною механизмами (может быть и ещё какими либо другими).