10.10.2011 20:29, Dmitry Fedorov пишет:
10 октября 2011 г. 23:11 пользователь Oleksandr Gavenko написал:
Предприятие занимается разработкой ПО и имеет множество внутренних
библиотек/модулей, которые, для поддержания модульности, релизятся
(в настоящий момент) на FTP для возможности использовать
другими проектами.
Мерзкая мастдайщина и глупость.
Модули/библиотеки хотя бы внутри предприятия
должны быть доступны в исходных текстах
через систему управления версиями и собираться для каждого проекта.
Через неё же и управление доступом ro/rw к разным веткам, и файлам
для разных пользователей.
В моём случае это git и gitolite.
Надеюсь, все слышали, что kernel.org тоже переходит на gitolite?
Но как то мне не ясно каким образом разделять права на запись
между различными проектами различным персонам...
gitolite умеет.
Я также подумал об использовании SVN для хранения результатов сборки
(в основном это бинарные файлы).
Ещё одна мерзкая мастдайщина -- любые результаты сборки в репозитории
исходных текстов - мусор.
В репозитории исходных текстов должны храниться только исходные тексты
- то есть, то, что набрано пальцами человека.
Всё остальное - производное от них и создаётся автоматически.
SVN помоему очень плохо, особенно для двоичных файлов.
я для маленького проекта использую Mercurial в котором находятся
исходники, скрипт и список.
Скрипт считывает список с адресами загружаемых файлов и собственно
загружает эти файлы с ftp.
Т.е. при маленьком репозитории в несколько мегабайт я получаю
возможность докачать всякие справочники и книги в формате pdf, программы
и прочее раздув рабочую папку под гигабайт.
Для больших проектом мне кажется надо сделать всетаки FTP с возможностью
создавать новые папки и файлы, но не перезаписывать существующие и
продумать систему нумерации версий, чтобы один отдел не порушил труды
другого внеся изменения в свои бинарники, которые стали работать чуть по
другому.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
