Система контроля версий

[Авварон]

ufna
git gc юзайте

гит хранит объекту кусками и дубликаты удаляется. Этого в свн нет. Так что я не верю что репа свна жрет больше.

[Пантер]

Гитовая репа намного меньше свновской.

[Igors]

предлагаю взять процесс разработки трехмерной модели к примеру такой штуки - http://gallery.ufna.ru/content/Other/3D/mastadont_010019.jpg Каждый день - коммит в районе 300Мб, общий размер по окончанию модели с исходниками - около 1 Гб.

Це Ви вже "геть знахабнiли" - уже и модели/текстуры (т.е. файлы данных) апдейтите на автомате. Тут дай бог с исходниками разобраться

Edit: кстати о птичках - где тут 300 метров? (http://gallery.ufna.ru/content/Other/3D/mastadont_010019.jpg). Модель простенькая, ну метров 5-10 даже в жирном текстовике. Текстуры - пошленький FractalNoise, так он "procedural" ото и все. Чего "раздувать"?

[ufna]

ufna
git gc юзайте

гит хранит объекту кусками и дубликаты удаляется. Этого в свн нет. Так что я не верю что репа свна жрет больше.

Это все отлично подходит для кода в виде исходников. Там да, гитовский репозиторий меньше. Для бинарников - тем более частно изменяющихся (причем не как экзешник, а как файлы, между которыми может быть почти ничего общего) - это не так.

P.S. - невозможность чекаутить по частям - это гораздо более сильный минус С размерами репозитория еще можно смириться, но с хранением всего репозитория арта - вот точно нет.

[Авварон]

ufna
git gc юзайте

гит хранит объекту кусками и дубликаты удаляется. Этого в свн нет. Так что я не верю что репа свна жрет больше.

Это все отлично подходит для кода в виде исходников. Там да, гитовский репозиторий меньше. Для бинарников - тем более частно изменяющихся (причем не как экзешник, а как файлы, между которыми может быть почти ничего общего) - это не так.

P.S. - невозможность чекаутить по частям - это гораздо более сильный минус С размерами репозитория еще можно смириться, но с хранением всего репозитория арта - вот точно нет.

Хранить копию файла целиком ВСЕГДА занимает больше места, чем хранить куски. Даже если в файле нет одинаковых кусков, размер как минимум будет таким же.

Чекаут по частям не нужен.

[iroln]

Чекаут по частям не нужен.

Это ещё почему?

[Пантер]

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

[ufna]

Хранить копию файла целиком ВСЕГДА занимает больше места, чем хранить куски. Даже если в файле нет одинаковых кусков, размер как минимум будет таким же.

Чекаут по частям не нужен.

Если файл не изменяется - тогда да. А когда этого файла -  версий десять подряд, размер файла ~300-400Мб? Насколько мне память не изменяет, гит будет хранить все это на локальной машинке. В SVN'е - достаточно хранить у себя последнюю версию.

Чекаут по частям - ОЧЕНЬ нужен. Вы представляете себе размеры арт-репозитория, о котором я веду речь? Отдельным исполнителям - не нужно все это, даже с быстрым интернетом. Не говоря уже об апдейтах. Размер репозитория - это напрямую время на чекауты/апдейты.

[Авварон]

ну в общем фигня война. короче вам нужна файлопомойка с версионностью, коей и является свн.

[ufna]

  как я уже сказал, для разных целей - свои решения. в 90% проектов на данных момент у нас гит.

еще камень в сторону гита - это его работа с symlink'ами. Она ужасна.

[Пантер]

Отдельным исполнителям - не нужно все это, даже с быстрым интернетом.

Опция --depth

[ufna]

Опция --depth

Да, согласен. Правда я имел в виду, что к примеру звуковику совершенно не нужна вся остальная часть с моделями и т.п.

[ufna]

на самом деле очень радует совместимость svn-git в обе стороны

[Пантер]

на самом деле очень радует совместимость svn-git в обе стороны

Угу. На работе приходится им постоянно пользоваться, так как все на свне.

[Авварон]

на самом деле очень радует совместимость svn-git в обе стороны

Угу. На работе приходится им постоянно пользоваться, так как все на свне.

и мне:(