Хранение прав доступа к файлам в репозитории Subversion

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

Блокировка не решит эту проблему. Блокировка запрещает другим редактировать файл. Это стороннее приложение, которое запускается как часть процесса сборки, которое пытается записать в файл - изменить его - что прерывает процесс сборки. Поэтому нам нужно запретить программе изменять файл, который просто помечает файл как доступный только для чтения. Мы хотели бы, чтобы эта информация хранилась в репозитории и передавалась через чекины, ветки и т. д.

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

Этот скрипт просматривает вашу копию кодовой базы и устанавливает разрешения на чтение для определенных файлов.

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

Грэм, svn не хранит разрешения. Единственный вариант - заключить вызов svn в сценарий. Сценарий должен вызвать svn со своими аргументами, а затем установить разрешения. В зависимости от вашей среды вам может потребоваться вызвать сценарий svn и настроить PATH, чтобы обеспечить его вызов.

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

Для этого мы создали командный файл. Хотя предпочел бы реальную поддержку в подрывной деятельности ...

Нет собственного способа хранить права доступа к файлам в SVN.

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

SVN уже давно имеет возможность обрабатывать символические ссылки и исполняемые файлы специально, но ни одна из них не работает должным образом в Win32. Я бы не стал задерживать дыхание ради другой такой непереносимой функции (хотя ее было бы не так уж сложно реализовать поверх уже существующей системы метаданных).

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

SVN действительно имеет возможность хранить метаданные (характеристики) вместе с файлом. Свойства в основном представляют собой пары ключ / значение, однако есть некоторые специальные ключи, такие как 'svn: executable', если это свойство существует для файла, Subversion установит исполняемый бит файловой системы для этого файла при извлечении файла. Хотя я знаю, что это не совсем то, что вы ищете, этого может быть достаточно (для меня).

Есть и другие свойства для окончания строки (svn: eol-style) и mime-типа (svn: mime-type).

@morechilli:

Обертка asvn из моего предыдущего сообщения и блог в сообщении OP, похоже, делает то, что вы предлагаете. Хотя он хранит разрешения в свойствах репозитория соответствующих файлов, а не в одном внешнем файле.

Этот - это обновленная ссылка на патч SVN, который правильно обрабатывает права доступа к файлам в стиле unix. Я тестировал Fedora12 и, похоже, работает так, как ожидалось:

Я просто сохранил его / usr / bin / asvn и использую asvn вместо команды svn, если мне нужно правильно обрабатывать разрешения.

Я бы рекомендовал сгенерировать карту разрешений с помощью утилиты mtree (она есть во FreeBSD по умолчанию), сохранить карту в репозитории и, как упоминалось выше, запустить скрипт, который восстановит правильные права доступа к файлам с карты в качестве первого шага процесс сборки.

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

1. chmod 755 badpermission.dll
2. mv badpermission.dll ../
3. svn update
4. svn rm badpermission.dll
5. svn commit badpermission.dll -m "Удалить dll для исправления разрешений"
6. mv ../badpermission.dll.
7. svn добавить badpermission.dll
8. svn commit badpermission.dll -m "Добавить dll обратно, чтобы исправить разрешения"
9. rm badpermission.dll
10. svn update
11. badpermission.dll возвращается с разрешениями на выполнение

Поскольку это еще не было полностью сказано в предыдущих ответах. Я ненавижу воскрешать зомбированные темы.

Поскольку добавление поддержки разрешений для SVN должно учитывать несколько типов ОС и разрешений, NFS, POSIX, ARWED и RACF.

Это сделало бы SVN раздутым, возможно, столкнувшись с конфликтующими типами разрешений, такими как NFS и POSIX, или открыло бы возможные эксплойты / уязвимости безопасности.

Есть несколько обходных путей. pre-commit, post-commit, start-commit являются наиболее часто используемыми и являются частью системы Subversion. Но позволит вам контролировать разрешения на любом языке программирования, который вам нравится.

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

Owner, Group, Folders, Files
default: <user> www-user 750 640
/path/to/file: <user> non-www 770 770
/path/to/file2: <user> <user> 700 700

Вы также можете расширить это и разрешить такие вещи, как автоматическое перемещение, их переименование, тегирование ревизий по типам, таким как альфа, бета, кандидат на выпуск, выпуск

Что касается поддержки клиентов для проверки файлов вашего репозитория с прикрепленными к ним разрешениями. Лучше подумать о создании установщика вашего пакета и предложить его в качестве ресурса.

Представьте, что люди устанавливают свои репозитории с исполняемым файлом в нем с разрешениями root: www-user 4777