git и подпроекты

оказывается это не возможно, абыдно ...

А, дурацкий вопрос, один и тот же файл в git может принадлежать разным (под)проектам? Т.е. чтобы несколько разных проектов могли использовать частично общие, частично различающиеся файлы?

Я немножко пытался найти систему контроля версий, чтобы баловство с подмодулями было максимально в стиле CVS.

Получается 2 разных проблемы:
1.
вытягиваение синхронно всех HEAD всех проектов - это смахивает на просто каталоги.
/rep
 -,
   /libproj1
   /libproj2
   /util1

В svn это можно сделать через svn:externals. Причем пути к репозиторию могут быть как локальными(вроде появились в недавних версии) так и абсолютными (с именем хоста, где он лежит).

В git-submodule это наверное можно было бы сделать, если вместо sha1 состояния модуля написать символьное имя (мне показалось, что это сделать нельзя). Пути к репозитариям только абсолютные. Вытягивать подмодули нужно явно после вытягивания проекта. Почти не пользовался, но показалось не очень удобным.

В darcs это обычно делается вытягиванием из разных репозиториев (через свой скрипт).

2.
попытка повесить таг/сделать ветку на всё это мясо с подмодулями.

В svn нужно писать свои скрипты, которые вешают таги на подмодули и перебивать в тегированном проекте(вложенных подпроектах) ссылки на externals.

В git-submodules это делается автоматически (tag).

Мне кажется, что модули - это некий идиотский концепт, которым лучше не пользоваться. Слишком много геморроя возникает при переезде с 1 системы контроля версий на другую. Проще держать проекты самодостаточными насколько это возможно, вводить версии библиопек и контроллировать их при сборке/исполнении продукта.

Я тоже занимался этой проблемой. Максимум до чего дошёл -- hgforest (расширение для Mercurial). Но это немного не то. В итоге пока использую Subversion. Если найдёте решение, то сообщите сюда -- rush.william@gmail.com (устраивает решение для любой Distributed VCS: Darcs, Mercurial, git, etc)

А как subversion-то спасает? Там конечно можно скопировать кусок дерева файлов, но дальше он уже будет самостоятельным. Или я чего-то не понимаю?

>А как subversion-то спасает? Там конечно можно скопировать кусок дерева файлов, но дальше он уже будет самостоятельным. Или я чего-то не понимаю?

Там это делается через svn:externals. Атрибут такой.

>> А как subversion-то спасает? Там конечно можно скопировать кусок дерева файлов, но дальше он уже будет самостоятельным. Или я чего-то не понимаю?

> Там это делается через svn:externals

И чем это лучше forest? IMNSHO, svn:externals - тупейший до бесполезности и легко эмулируемый механизм.

>svn:externals - тупейший до бесполезности

Аргументы?

>и легко эмулируемый механизм.

Пример?

Спасибо, не знал. Почему-то я как-то мимо этого момента проскочил...

Бегло полистал hgbook, который вы мне как-то порекомендовали. Возник вопрос: Могут ли быть в одном репозитарии mercurial сразу несколько веток? (и желательно их все сразу вытягивать, как в git, svn)

> Могут ли быть в одном репозитарии mercurial сразу несколько веток?

Да, конечно.

> желательно их все сразу вытягивать, как в git, svn

Этого не понял. "Вытягивать" - это pull? По умолчанию hg pull забирает из репозитория-источника всё, чего нет в целевом репозитории.

>> svn:externals - тупейший до бесполезности

> Аргументы?

Насколько я помню, он ничего не умеет, кроме как вытаскивать указанные в проперти репозитории?

>>и легко эмулируемый механизм.

>Пример?

В Mercurial есть хуки для pre-имякоманды. Можно повесить то же самое на ./configure. Можно сделать кучу разного всего, и это даже нетрудно.

Да, и что не так с hgforest? Я вот думаю его заюзать :)

>Насколько я помню, он ничего не умеет, кроме как вытаскивать указанные в проперти репозитории?

Ну, немного расширенней -- можно указать вытягивать определённую ревизию.

>В Mercurial есть хуки для pre-имякоманды.

И как сделать ... *осёкся* Я -- тормоз. Ведь Mercurial на Python! Т.е. уже гарантируется, что он (Python) будет на конечной машине. Спасибо.

/me пошёл пилить хуки