modern DVCS

[wizzard]

я вот тут решил попробовать мигрировать на новомодные нынче git/hg, и возник вопрос – а в них как вообще чекаутить часть репозитория?

а то у меня то ли снега нету, то ли лыжи не едут, в общем, не вижу я этого в упор в документации, и всё…

зачем это нужно:
а) разделение прав доступа девелоперов к частям проекта, вплоть до отдельных файлов (сертификаты, например)
б) если репо более 10-20 Гб, чекаутить его весь неудобно, как бы быстро это ни происходило. да, я держу в версионнике медиа-контент, а не только текст. версионировать его отдельно – это можно чокнуться.

Comments

[wizzard]

Да, а проблема с правами доступа в том, что в патологическом случае права доступа - это матрица user * resource, а если делить на репозитории-"компоненты", то может в итоге так случиться, что будет по репозу на папку\файл (что неудобно), или каждому юзеру будет по отдельному мелкому репозу, и тогда немного непонятно, зачем вообще версионироваться (ну, кроме бекапов)

[lionet.livejournal.com]

С правами доступа в _D_VCS традиционно не заморачиваются. Ибо архитектурно неприятно.

[wizzard]

Да, я понимаю, что central authority нету, а без нее надо много заморачиваться с графом доверия. Также, насколько я понимаю, гит быстрее, т.к. ему не надо для операций ходить к этой самой авторити.

В связи с этим вопрос - не бывает ли версионников, которые выполняют операции типа того же свича\мержа на сервере, а секьюрити управляют на границе "сервер-девелопер"?

[lionet.livejournal.com]

Примерно то, что тебе нужно — svn, perforce, clearcase ;)

[wizzard]

Эх ;)

[kurilka.livejournal.com]

есть gitosis, но у нас очень несложное разделение прав (релизят ответственные)