10.10.2011 20:36, Sergey Stremidlo пишет:
SVN помоему очень плохо, особенно для двоичных файлов. я для маленького проекта использую Mercurial в котором находятся исходники, скрипт и список. Скрипт считывает список с адресами загружаемых файлов и собственно загружает эти файлы с ftp. Т.е. при маленьком репозитории в несколько мегабайт я получаю возможность докачать всякие справочники и книги в формате pdf, программы и прочее раздув рабочую папку под гигабайт. Для больших проектом мне кажется надо сделать всетаки FTP с возможностью создавать новые папки и файлы, но не перезаписывать существующие и
*не перезаписывать существующие* ОЧЕНЬ хорошая мысль.
По идее все что релизится не должно перезатираться. QA отдел же находит ошибки в *конкретной* версии, если версия не указывает на сущность - это плохо - нет воспроизводимости. Правда это требование очень сильное, но если и его выполнить, тогда у меня будет безупречная модель. Кажется в SVN в хуке можно отличать ADD от CHANGED и тут же рубать. И вроде для FTP сервера команда STOR перезаписывает файл... с FTP такой цели не достичь.
продумать систему нумерации версий, чтобы один отдел не порушил труды другого внеся изменения в свои бинарники, которые стали работать чуть по другому.
Это продумно! [MAJOR].[MINOR].[REV] с семантикой как описано в libtool документации для библиотек + с учетом материала: http://www106.pair.com/rhp/parallel.html Что то мне идея с SVN все больше нравиться: * обеспечивается атомарность (в комите путь /[vendor]/[product]/[version]/[platform] может создать только один клиент, другой получит конфликт) * хуками скорее всего можно исключить возможность внесения модификаций в существующие файлы * удобно настраивать права доступа * аутентификация из существующего LDAP (с ssh нужно создавать кучу UNIX групп и пользователей) * файлы анонимно раздаються по HTTP * сохраняется метаинформация о том кто и когда добавил В принципе любая DVCS скорее также подойдет. Кажись Red Bean'овцы хвастали в SVN book хорошей работой с бинарными файлами. Оригинальный дизайн, з думкою про Вас. Попробую протестировать. производительность. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j6vpm6$s8v$1...@dough.gmane.org