Лицензированные материалы в DVCS. Правовые вопросы.

Существует ли механизм безвозвратного удаления материала из истории?

в git — существует. :)

Для mercurial:

Битбакет позволяет удалить ревизию со всеми потомками из репозитория, - это называется strip changesets. Так что механизм такой: переписываем историю ревизий таким образом, чтобы материала там не было, затем push'им полученную ветку в битбакет, после этого удаляем на битбакете старую ветку. Ну и у себя локально можно удалить эту ветку - hg strip.

переписываем историю ревизий таким образом, чтобы материала там не было

А это как?

хранить блобы на жестком диске, а в dvcs - только ссылки?

http://mercurial.selenic.com/wiki/HisteditExtension

git rebase --interactive

? :)

хранить блобы на жестком диске, а в dvcs - только ссылки?

Имеется в виду перенос всей коллективной работы с сайтом в DVCS: Сайты в DVCS. Есть такое?

git rebase --interactive

Э... Разбирать ручками несколько тысяч коммитов? o_O

Нет, мне нужно что-то типа hg histdel --force path/to/file.ext

Зависит от того, насколько давно материал был добавлен, и менялся ли он впоследствии.

Если материал был добавлен давно, и после него были мерджи, отведение новых веток и пр., то такие расширения как hg histedit могут не справиться, хотя можно попробовать (на последней версии mercurial). В любом случае идея такая: выполняем hg update до ревизии, родительской к той, где материал был добавлен (назовём её проблемной ревизией). Затем выполняем hg export проблемной ревизии, получаем файл с патчем. Редактируем этот файл, убирая лишние данные. Затем выполняем hg import. Получили новый вариант ревизии, в котором нет лишних данных. На него сверху накатываем остальные ревизии без изменений. Расширения типа hg histedit упрощают этот процесс.

Ну, в SVN можно редактировать описания коммитов, потому что это unversioned resources. Аналогично, если версионирование блобов написать самостоятельно, в обход основного dvcs, удаление закопирасченых блобов будет делать легко и быстро... Там, каждый новый блоб называется чиселкой, на единицу большую чем предыдущий, что-нибудь такое :))) А в самой CMS сделать открытие файла по некой file handle, в которой вся логика поиска файла упрятана в черный ящик (поиск файла внутри dvcs, внутри БД, на «самостоятельно версионируемом» куске диска, на неверсиоируемом куске диска, по http с других серверов, итп). Сидеть и штрафы ведь хуже? :)

Зависит от того, насколько давно материал был добавлен, и менялся ли он впоследствии.

В общем случае может быть, что материал был добавлен как угодно давно, менялся, переносился по новым адресам... И нужно сделать так, чтобы он стал недоступен.

В любом случае идея такая

Угу. Примерно понял. Нужно будет попробовать.

Мне по долгу службы нужно возиться с исходником, который написан для Windows, но запускается на Linux с помощью набора патчей. Понятно, что такие патчи в апстрим никто не примет, там же богомерзкая Linux, фу-фу. Поэтому делается двумя способами. Вначале чисто скачанный репозиторий накатываются изменения из соседнего бранча с «магическими патчами». Потом каждое Linux-специфичное изменение коммитается с комментарием, содержащим строку !LINUX_COMPAT. Перед коммитом, из рабочего бранча удаляются все коммиты «магического бранча», все linux-compat коммиты переносятся в «магический бранч» и удаляются из рабочего, получается зачищенный от линукс-скверны бранч, который можно коммитать в апстрим или высылать по почте. Еще есть специальный блеклист коммитов в файле commit-blacklist-id.txt и commit-blacklist-regexp.txt (одна строка - один коммит, идентификация по айди или по регэкспу в комментарии соответственно), они вычищаются каждый раз перед коммитом без сохранения куда-либо.

Может, сделать что-то подобное. Поиск по комментарию, с маркером !FILE_BLOB=path, и последующим вычищением таких коммитов. Или реестр коммитов с файлоблобами по id. Или отдельный бранч с черрипикнутыми файлоблобами, с которым можно потом устроить пересечение.

Разбирать ручками несколько тысяч коммитов?

https://help.github.com/articles/remove-sensitive-data

В общем случае может быть, что материал был добавлен как угодно давно, менялся, переносился по новым адресам... И нужно сделать так, чтобы он стал недоступен.

Можно попробовать использовать hg convert с опцией --filemap.

Понятно, что такие патчи в апстрим никто не примет

Для этого есть mercurial queues, насколько я понимаю. Как в git с этим - не в курсе.

Можно попробовать использовать hg convert с опцией --filemap.

Только зашёл, чтобы отметиться о нахождении простого решения :) Действительно, hg convert repo-original repo-stricted --filemap fm.txt, где в fm.txt — «exclude restricted-file». Сейчас на тесте проверил, вычищается целиком.

Ага, причём идентификаторы ревизий до первого добавления файла остаются прежними, и если ревизия добавляет/изменяет только этот файл, то она вообще исчезает. То, что доктор прописал. :)

вот нагуглил как с этим в гите: http://stackoverflow.com/questions/2164581/remove-file-from-git-repository-hi...

Чуть выше ссылка на примерно такое же решение. Жуть, в общем :)

Линус бы показал фак копирастам и сказал бы нечто вроде «гит - не место для постинга своих высеров, проклятые копирасты! Я не против патентов, но только не в моем гите! Убирайтесь отсюда, короче!» :)

гит - не место для постинга своих высеров, проклятые копирасты!

Тут проблема, как раз, в другом, что копирасты могут сказать — уберите наш высер из вашего гита! :)

Пока кодишь, проблема не так актуальна, а вот файлы и фото чистить уже приходилось не раз. Пока хоть без DVCS было. А сейчас буду контент на DVCS переводить, вот тут задача и может вылезти.

Ну чего им там не сидится? Пока они эти тонны писем пишут, могли бы тридцать два раза новую фотку мячика в луже сфотографировать и накопипастать копипастанную новость... Интересно, можно ли тупо забить на все эти высеры? За кем-нибудь уже приходили?

//линус не принимает в ядро фоточки, и рэпчик на загрузку нельзя поставить ((( Хотя бы благодаря Леннарту теперь картинки есть, ну, QR-коды :)

Интересно, можно ли тупо забить на все эти высеры? За кем-нибудь уже приходили?

Ну, один раз я проигнорил слишком уж неофициальный наезд (по e-mail с непонятного адреса — мало ли кто чего напишет, так и ответил), так уже через управление-Р (или тогда было -К? — я в них путаюсь) на хостера вышли ругаться.

Правда, с 2004-го нового контента нет на сайте, так что с тех пор от копирастов претензий не было. Только от недремлющих органов по некоторым сообщениям на форуме, несколько раз удалять приходилось :)

Читаем FAQ по git, как убить файлик с паролем. И да, mercurial не нужен.

А зачем делать сам репозиторий открытым для каждого встречного? Исходные коды сайта это же коммерческая инфа, если даже модифицировались открытые компоненты, то чистенький и культурненький тарболл с исходниками и патчами всегда можно экспортнуть для всех желающих по реквесту. А облитерэйшен не нужен. Разве что как в svn, дамп - хакинг дампа - восстановление из дампа.

Исходные коды сайта это же коммерческая инфа

CC BY-NC-SA рулит :)