Mercurial: возможно ли такое?

Насколько я знаю, такое не получится.

Есть «вариант» - создай ещё один репозиторий и добавь туда нужные файлы. Дальше нужно их оба синхронизировать.

P.S. А вообще это похоже на плохой «дизайн» системы. Кажется, это уже обсуждалось недавно, там бы яростно отстаивал правильность своего решения :)

А вложенные репозитории для этого не пойдут? http://mercurial.selenic.com/wiki/subrepos Там уже можно и отдельно историю вести, и archive делать и всё остальное. Хотя, насколько я знаю, для создания тарбола с исходниками обычно используют правила make.

А чем -I -E в hg archive не устраивает?

> Можно ли как-то пометить (тэгами?) определённые файлы в репозитории

Средствами Mercurial - нет. Но, по-моему, для этого тривиально делается что-нибудь в духе .hgignore.

>Есть «вариант» - создай ещё один репозиторий и добавь туда нужные файлы. Дальше нужно их оба синхронизировать.

Неудобно.

А вообще это похоже на плохой «дизайн» системы.

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

Кажется, это уже обсуждалось недавно, там бы яростно отстаивал правильность своего решения :)

Это где?

Там уже можно и отдельно историю вести, и archive делать и всё остальное

Нет. Нужен именно один и тот же файл, но в разных комплектах.

А чем -I -E в hg archive не устраивает?

Слишком громоздко. И требует постоянной ручной возни, даже если в скрипт прописать. Мало ли, файл переместился в другое место и т.п. Хочется один раз пометить и забыть.

Средствами Mercurial - нет.

А в git, например, такое возможно?

> > А вообще это похоже на плохой «дизайн» системы.

Есть мысли, как это реализовать «хорошо»?

«Жирное» «ядро» системы и несколько вариантов «ядра» - это как-то абсурдно. По-идее, у тебя должно быть одно «ядро», а к нему уже разные «плюшки», плагины и прочие расширения.

Вариантов решения я вижу два. Одно - это разные дирки для ядра и для расширений. Вариант другой - ты раскидываешь файлики как тебе угодно, а перед экспортом/запуском строишь финальную структуру проекта.

>«Жирное» «ядро» системы и несколько вариантов «ядра» - это как-то абсурдно

Нет, ядро там маленькое :) Но очень широкий спектр компонентов. При чём - часто пересекающихся.

Разделять всё на сотни модулей - получается бред.

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

По-идее, у тебя должно быть одно «ядро», а к нему уже разные «плюшки», плагины и прочие расширения.

Вот проблема в реализации конкретных комплектов этих «плюшек».

Одно - это разные дирки для ядра и для расширений.

Не катит, так как проблема именно в разделе расширений.

Вариант другой - ты раскидываешь файлики как тебе угодно, а перед экспортом/запуском строишь финальную структуру проекта.

Опять неудобно.

...

Неужели нет ни одной популярной VCS, где можно повесить на файлы тэги и потом экспортировать проект с заданным набором тэгов?

Собственно, совсем уже конкретизированная задача.

Есть PHP-фреймворк. Собственно ядро - очень мелкое, поэтому говорить речь идёт не о нём, а о базовом наборе расширений. На десяток файлов ядра это где-то за пять сотен файлов расширений.

Теперь хочется на основе этого фреймворка делать базовые готовые CMS в разных сочетаниях, чтобы пользователь мог не заморачиваться выкачиванием тонны ненужного ему кода, а сразу скачать минимальный архив с заданными свойствами (зачем ему поддержка Oracle, если ему посмотреть или развернуть простую систему хватит plain-text бэкенда?).

При этом заводить N разных субпроектов, синхронизированных с основным - очень неудобно.

Со временем, наверное, реализую пакетный менеджер и тогда вопрос решится проще, но когда ещё до такого руки дойдут... :) А пока думалось, что уж такая-то фишка в современных VCS, как пометка файлов есть. Увы, нет :-/

> > Кажется, это уже обсуждалось недавно, там бы яростно отстаивал правильность своего решения :)

Это где?

Я вот примерно то же спрашивал: http://www.linux.org.ru/view-message.jsp?msgid=4080164