Это так же не подходит для часто меняющихся данных — типа контента игрушек, который надо версионировать вместе с кодом зачастую, чуть ниже я писал об этом. Настройки — ерунда на фоне администрирования Свн-сервера конечно.
Из-за того, что это «извращение» запретили многие компании Свн-ом дальше 1.6 пользоваться не станут, т.к. при больших репо возможность забрать и поправить часть — критичная фича.
Это только один пример. В геймдев конторах, например, гигабайты может занимать контент без которого невозможно игру запустить. Бить его на части, поддерживать по разным репозиториям и т.п. — большой и кропотливый труд, которым зачастую просто некому заниматься.
Да, Вы правы, мне почему-то подумалось про работу с svn-сабрепо через hgsubversion. В Свн держать часть файлов вполне можно. Не считая усложнения настройки и доп. работы админам — думаю, это наиболее удобное решение.
Во всяком случае куда более удобное, чем сторонние тулзы для обновления зависимостей, особенно если нет необходимости «работать на другом конце земли и иметь всю историю изменений у себя», что требуется далеко не всем.
Там, не add, а add+, в этой операции есть информация об источнике и ревизии исходного файла или каталога. Если у Вас ее нет, возможно, версия Свн-а старовата.
Это опасный путь. Во-первых, сам по себе сабрепо не решит проблемы нехватки памяти на 32ух-битных машинах и долгих апдейтов с диким потреблением памяти на остальных. Во-вторых, сабрепо требует еще пары очков в скиллах, чтобы им пользоваться, настраивать и т.п. Это все определенно не ляжет на чашу весов в пользу перехода на новую систему контроля версий.
Если менялся, то, конечно, будет. Однако скачать гигабайт по гигабитной сети, как выяснилось на практике, быстрее, чем дождаться, когда Меркуриал переварит гигабайтный дифф.
Хм… как в Свн-е перенести локальные изменения из переименованного в новый файл?
В Свн, кстати, «добавить новый файл» и «скопировать существующий файл» — разные операции, т.ч. история копирования файла у него в общем-то есть.
Только посмотрите, что вышло из «безболезненного перехода»: надо всех научить пользоваться новой системой, поставить всем софт, рассказать про отличия, набить шишек, переделать скрипты, написать пачку новых, еще набить шишек, потратить Х часов каждого человека на вышеописанные процессы, натренировать админов, а потом, вот уже потом, сэкономить на времени апдейтов и мержей в течение хода проекта, и то не для всех членов команды, т.к. 2/3 и так не имели с этим проблем.
Встает закономерный вопрос: а есть ли у проекта время на все это, с учетом надвигающихся дедлайнов? Нередко, в силу рисков и затрат, дешевле и спокойнее остаться на том, что работает, пусть и не идеально. Что, разумеется, не отменяет возможности использовать Меркуриал/Гит на местах с Свн-ом в качестве центрального репозитория.
В крупных конторах поменять все пользовательские машины, билд-сервера, плюс операционки — вполне себе длительный и дорогостоящий процесс. Хотя вы безусловно правы, 32-бита становятся проблемой все меньше.
Я знаю множество проектов, у которых один только транк будет весить значительно больше гигабайта. Большинство современных игр для PC и консолей входят в это число.
Последний раз, что я видел — была пачка lib+pdb+dll файлов от сторонней библиотеки. Работа с одним ченж-листом съедала 4ГБ памяти в Меркуриале. Вынести их из репозитория нельзя, т.к. их надо версионировать вместе с кодом.
Если пришло переименование измененного файла — переименовать. Если пришло изменение в переименованном файле — перенести изменения в файл с новым именем. По меньшей мере предложить такие варианты, а не оставлять все на ручную работу.
Странный аргумент. По пачке рабочих копий на разных машинах — это не «размазаны»? Или Вы об отсутствии центрального сервера? Так его можно поставить и для Гита/Меркуриала, какие проблемы…
Во всяком случае куда более удобное, чем сторонние тулзы для обновления зависимостей, особенно если нет необходимости «работать на другом конце земли и иметь всю историю изменений у себя», что требуется далеко не всем.
Если менялся, то, конечно, будет. Однако скачать гигабайт по гигабитной сети, как выяснилось на практике, быстрее, чем дождаться, когда Меркуриал переварит гигабайтный дифф.
В Свн, кстати, «добавить новый файл» и «скопировать существующий файл» — разные операции, т.ч. история копирования файла у него в общем-то есть.
Только посмотрите, что вышло из «безболезненного перехода»: надо всех научить пользоваться новой системой, поставить всем софт, рассказать про отличия, набить шишек, переделать скрипты, написать пачку новых, еще набить шишек, потратить Х часов каждого человека на вышеописанные процессы, натренировать админов, а потом, вот уже потом, сэкономить на времени апдейтов и мержей в течение хода проекта, и то не для всех членов команды, т.к. 2/3 и так не имели с этим проблем.
Встает закономерный вопрос: а есть ли у проекта время на все это, с учетом надвигающихся дедлайнов? Нередко, в силу рисков и затрат, дешевле и спокойнее остаться на том, что работает, пусть и не идеально. Что, разумеется, не отменяет возможности использовать Меркуриал/Гит на местах с Свн-ом в качестве центрального репозитория.
Я знаю множество проектов, у которых один только транк будет весить значительно больше гигабайта. Большинство современных игр для PC и консолей входят в это число.