>все данные УДВАИВАЮТСЯ

А ты как хотел? Откуда иначе данные будут восстанавливаться, из /dev/null?

В любой vcs будет создаваться хранилище содержащее все твои данные.

Дудочка или кувшинчик.

Тут либо дудочка, либо кувшинчик. Либо вы храните целую гору ваших данных в SVN, и из репозитерия можете их восстановить, либо не храните, и не можете восстановить.

У SVN ещё особенность, имея репозитарий на сотню ревизий нельзя простым способом удалить данные о первых 50. Репозиторий специально сделан таким образом, чтобы из него был предельно трудно что-то удалить. Кажися в Git'е не так, присмотритесь к нему.

>Репозиторий специально сделан таким образом, чтобы из него был предельно трудно что-то удалить

странно, что разработчики svn не подумали, что при использовании контроля версий часто бывает нужно удалить файл/каталог из под контроля (например попавший туда по ошибке, или ставший ненужным) ?

да и ".svn" в каждом каталоге сильно мешает как удвоением размера, так и неудобством поиска

замени svn на git, хоть будешь знать чо хранишь)

странно, что разработчики svn не подумали, что при использовании контроля версий часто бывает нужно удалить файл/каталог из под контроля (например попавший туда по ошибке, или ставший ненужным) ?

вопрос что важнее - четкая, «честная» последовательность версий или мегабайты жесткого диска.

а то так вот поудаляешь «ставшими ненужными» файлы, а потом не сможешь ревертнуться к точке когда они еще были нужны

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

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

аффтар вероятно хочет снапшоты с возможностью просматривать диффы?

ps. капча our ludining

>> когда мне нужно удалить файл из репозитария - я четко понимаю что я делаю, понимаю что история мне более не нужна для этого файла

Так не бывает. Тем более, что оно сделано прежде всего для исходников. История удаленного файла может потребоваться например начальству :)

Я не понимаю как можно вкомитить левый файл, если он тебе показывает список файлов для комита и просит написать коментарий зачем ты это комитишь. Аккуратнее надо быть...

так можно продолжить логику, что если создал любой файл на диске, то теперь его не удалить - ведь пользователь знает зачем он файл создал и имя ему назначил, аккуратнее надо быть )

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

> программа обычно развивается, и со временем часть файлов становится ненужной

Ы? Полное непонимание принципов работы VCS детектед.

Хранилище на то и существует, чтобы из него можно было извлечь корректные и полные данные для произвольной ревизии. Если файл был нужен N ревизий назад, то ненужным он стать не может по определению. Фарш невозможно провернуть назад.

З.Ы. Капча pulper system намекает.

>к SVN есть конкретная претензия - все данные УДВАИВАЮТСЯ

Не совсем так. Если в локальном .svn данные дейтсивтельно дублируются, то в серверном репозитории файлы не множатся в ростом версии репозитория, если они не менялись.

В общем случае, размер репозитория _не_ растет со скоростью (размер ценных данных * количество коммитов).

А локальный .svn можно и удалять после коммита.

позволь всеже пользователю VCS решать нужен мне файл и его история далее или нет
например я решил вывести файл из под контроля VCS - почему я не могу этого сделать ?

>> позволь всеже пользователю VCS решать нужен мне файл и его история далее или нет

например я решил вывести файл из под контроля VCS - почему я не могу этого сделать ?

Не позволим :) Одна из основных задач VCS - возможность отката на _произвольную_ версию в прошлом.

То что ты хочешь называется как угодно, но только не VCS.

Хотя например в CVS можно было удалять файлы и каталоги насовсем, командой rm -f /home/cvs/cvsroot/repository/path/to/file.v на сервере. Как то так..

Потому что VCS не даёт тебе выстрелить себе в ногу и правильно делает. VCS — это машина времени, а прошлое изменить невозможно.

Если ты хочешь выкинуть историю ревизий, сделай export рабочей копии и создай на её основе новое хранилище с нуля. А старое торжественно подвергни экстерминатусу.

невозможность удалять файл\каталог из хранилища - это негибкость системы

т.е. если я по ошибке закоммитил большой файл, то он теперь как балласт будет болтаться в репозитарии ? очень умное поведение, да

и я не хочу терять всю историю, мне только один файл/каталог нужно удалить

странно вообще слышать эти оправдания, как нежелание разработчиков svn реализовать данное поведение, желаемое многими пользователями, причем эти пользователе сами являются разработчиками, что говорит об обоснованности желаемого

>> т.е. если я по ошибке закоммитил большой файл, то он теперь как балласт будет болтаться в репозитарии ? очень умное поведение, да

Да, учит смотреть внимательно, что коммитишь :)

А черезжопные методы удаления файлов есть наверное во всех VCS. Но черезжопные они специально, чтобы удаление файлов насовсем не становилось дурной привычкой.

>> желаемое многими пользователями, причем эти пользователе сами являются разработчиками, что говорит об обоснованности желаемого

Странные разработчики. Я еще ни одного такого за 15 лет трудовой практики не встретил. Обычно все хотят полную историю.

Мне кажется, на самом деле такая «VCS» — скорее из области версионности отдельных файлов на уровне ФС. Например, для хранения писем, черновиков, случайных заметок. Упомянутые разработчики определённо путают свой домашний каталог с хранилищем проекта. ;)

Скажем, очень полезна возможность удалить файлы насовсем, когда юзер точно уверен, что иметь на компе историю планирования хакерской атаки ему совершенно точно не нужно и даже вредно. :)

В данном случае мы имеем дело не с монолитным хранилищем множества файлов, которые должны быть согласованы друг с другом, а с ситуацией, когда произвольный каталог или файл может сам по себе является хранилищем. Но VCS такую задачу не решают, они собственно, для этого и не предназначены. Да и нет адекватных инструментов для организации таких мини-хранилищ — версионность на уровне ФС так и не прижилась за 30+ лет.

если думать о vcs как о контейнере, то должны быть методы помещения объекта в него, обновления и удаление из него

так и есть - например:

svn add && svn commit

edit && svn commit

svn rm && svn commit

:)

да, я понимаю, что это «странный» контейнер, который при удалении оставляет файл в себе как историю
но хотелось бы иметь svn obliterate, для тех, кто понимает зачем это нужно )

>> для тех, кто понимает зачем это нужно

Мне кажется те, кто понимает зачем это нужно пилят tux3. В VMS еще была забавная ФС - похоже как раз то, что тебе нужно.

В план9 подобная ФС. Ещё подобная функциональность есть в VMS/OpenVMS. Сделать похожую вещь можно с помощью снапшотов на ZFS (но это не совсем то).