Системы контроля версий - вопросы и странные хотения...

А у меня возникает вопрос - нафига нужна _ветка_ для раздачи? «Сборка занимает много времени» не катит за отмазку - просто рабочей копии хватило бы, и еще есть компиляционные кэши.

Дяденька, я во всей этой кухне не силен - университеты заканчивал, да не те...

Если Вы про рабочую копию как про просто набор исходников на сервере, то как юзер их накатит? rsync-ом?

Про компиляционные кэши не в курсе.

Зачем конечным пользователям VCS? Поставь Jenkins, собирай в нём бинарный архив из всего, что нужно, и выкладывай только его.

Есть проект, сборка которого с нуля может занимать довольно много времени, а обновления выходят довольно часто.

понятно

cоответственно, конечным пользователям хочется раздавать его через какую нить VCS

непонятно. Кого раздавать? дерево исходников? Архив исходников проекта? Скомпилированный и готовый к работе продукт?
VCS годится только для первого случая. Для остальных он вообще не в дугу.

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

непонятно. «Заливать» = «коммитить изменения _в_ репозиторий». Вы, наверное имели в виду «сливать» = «вытягивать новые изменения _из_ репозитория на локальную машину»? Верно?
Далее процесс сборки (а также вопрос скомпилированных кешей) очень сильно зависит от языка. C и make - одни пути, java и мавен - другие. Уточните пожалуйста.

Пока что мой одурманенный йогуртом мосг выдал следующую идею - ветку для раздачи не форкать а вести с нуля, с нуля же держать в ней только то, что нужно. Необходимые файлы из trunk гнать туда rsynk-ом, выкидывая по шаблону лишнее и добавляя то что надо сверху, а потом уже коммитить.

однозначно неверно. Вы либо раздаете все исходники, чтобы пользователь мог собрать полностью весь проект, либо делаете отдельное место, никак не связанное с системой контроля версий, для хранения и предоставления скомпиленных артефактов. (архив исходников = частный случай артефакта)

Вобщем, детализируйте вопрос, пожалуйста.

Если Вы про рабочую копию как про просто набор исходников на сервере, то как юзер их накатит? rsync-ом?

Для начала - зачем юзеру исходники? А накатывать он их может хоть tar. Конечно, tar не умеет дельта-обновление, но он хотя бы не накапливает архив в .hg или что там у bzr.

Я таки не понимаю, зачем юзеру исходники и VCS. Дать ему архив бинарей, пусть распует куда сам захочет.

Про компиляционные кэши не в курсе.

man ccache

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

Для начала - зачем юзеру исходники?

Собирать. Бинари не катят - под разные архитектуры разные сборки (32/64 бита как мин) + разные либы линкуются... Да и вообще это библиотека, которую юзер по ходу сам дособирает под свои нужды. C++ и питон.

Бинарей под VCS вообще нет (кроме картинок из документации, так они не меняются).

ЯП - С++ и питон, make.

Вы, наверное имели в виду «сливать» = «вытягивать новые изменения _из_ репозитория на локальную машину»? Верно?

Да, прошу прощения.

Вы либо раздаете все исходники, чтобы пользователь мог собрать полностью весь проект, либо делаете отдельное место, никак не связанное с системой контроля версий, для хранения и предоставления скомпиленных артефактов.

У меня ИМНО промежуточный случай. Ладно документация, пусть тащщут себе веник .tex файлов и картинок который сравним с иходниками кода как мин, если не больше - но свои todo я им не отдам!

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

С одной стороны плохо, с другой гораздо проще накатывать обновления. Я наоборот сейчас объединил 4ре проекта в один, поскольку они взаимодействуют (и изменения я в них иногда вношу синхронно), а лишние системы установки и раздачи настраивать не хочу. Связанность скорее все таки слабая, но она есть.

Тогда твоя идея сводится к «делаем обычные tarball'ы релизов, распаковываем их и помещаем в VCS-репозиторий для организации инкрементального обновления рабочих копий у пользователей». Ну, работать будет, не вопрос, но роль VCS сводится к организации транспорта обновлений.

лишние системы установки и раздачи настраивать не хочу.

скажите, а сервер Continuous Integration у вас есть?

скажите, а сервер Continuous Integration у вас есть?

Наск я знаю нет, и наверное и не предвидится...

Да, так будет правильно сказать. Мне интересно, насколько это содомичное решение и есть ли более прямые пути?

роль VCS сводится к организации транспорта обновлений.

На самом деле не совсем - еще VCS позволяет откатиться если релиз кривой;-) Так что похоже решение правильное.

Если пользователям нужны именно исходники, и они собирают продукт сами, я не вижу более прямого способа. Особенно с учетом нежелания отдавать todo, что исключает обычное клонирование основного репозитория.

Кстати, для такого сценария SVN подходит лучше, чем любая DVCS.

Ок, спасибо большое!

Кстати, для такого сценария SVN подходит лучше, чем любая DVCS.

К сожалению, для разработки именно DVСS куда лучше - неск раб мест, не всегда есть связь, и т.д. Да и чего то мне bzr начал нравиться несмотря на неспешность;-)

rpm

[s]rpm

VCS стоит юзать, только если пользователи могут вносить исправления и присылать их обратно.

Если да, ИМХО нужно разделить код на два репозитория - для разработчиков и пользователей.
Можно использовать общий подмодуль для обоих репозиториев с собственно кодом.

В git вместо этого можно использовать subtree merge:
http://progit.org/book/ch6-7.html
http://book.git-scm.com/5_advanced_branching_and_merging.html

под VCS лежит много такого, чего пользователю не нужно

очевидно, другая ветка

всякие todo

chiliproject/bugzilla/redmine/trac

напр. документация собранная в pdf

тот же chiliproject или субрепозиторий, если хочется

как в ветку для раздачи не положить лишнего и положить то что нужно?

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

Непонятно, зачем нужна ветка для раздачи, если для раздачи можно пометить биркой (tag) любой нужный набор файлов с нужными версиями (tag сделать)?

ЕМНИП tag не помеченные файлы не закрывает, и если тащить без тага придет все?

Tag просто метит так, чтоб потом удобно было взять то что нужно. Если нужно определённым пользователям запретить чтение/запись, нужно права доступа к файлам соответствующие установить.

CMake + CDash, он умеет найтли-билды последних ревизий. И просто билды определенных ревизий тоже умеет. И веб-интерфейс имеется.

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

Если нужно определённым пользователям запретить чтение/запись, нужно права доступа к файлам соответствующие установить.

Через http? Без авторизации?

Я вообще бинарники не выкладываю, только исходники.

Я не знаю как это делается конкретно в SVN. В CVS права доступа к файлам в CVSROOT определяют, кто куда может читать/писать.

В bzr при доступе через http анонимный пользователь получает всю ветку. В svn не знаю, я им не пользуюсь. В cvs разве есть анонимный доступ по http? Там же репозиторий лочить надо...

В cvs разве есть анонимный доступ по http?

Весь доступ по ssh.

Я как-то считал, что любая система контроля версий должна позволять устанавливать разные права доступа для разных пользователей. Разве нет?

не предвидится...

Милейший, в вашем случае я просто поставил CI на тестовый сервер, где он благополучно и прижился.

Весь доступ по ssh.

В данном конкретном случае http куда лучше подходит.

Милейший, в вашем случае я просто поставил CI на тестовый сервер, где он благополучно и прижился.

У меня нет тестового сервера.