Есть ли недостатки в использовании рабочей копии для живого сайта с SVN 1.7? - PullRequest
7 голосов
/ 09 января 2012

Я планирую опубликовать наш действующий сайт сегодня, и я прочитал, что лучший вариант - это использовать экспорт svn, чтобы избежать заполнения рабочей копии файлами .svn, однако это больше не проблема с SVN 1.7, так какметаданные хранятся в одном файле.Мне кажется, что использовать рабочую копию гораздо лучше, чем экспортировать, так как обновление живого сайта будет таким же простым, как и запуск svn update.Есть ли причина не извлекать рабочую копию и использовать экспорт?

Ответы [ 2 ]

2 голосов
/ 18 декабря 2012

Проблема с использованием svn update заключается в том, что слишком легко обновить ваш живой сайт. Вы можете обновить версию, которая не работает или не проверена.

Я бы порекомендовал вместо этого гибридный подход - перед выпуском новой версии пометьте его, затем svn переключите действующий сайт на этот тег.

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

1 голос
/ 20 января 2012

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

Как вы, возможно, уже знаете, Subversion сохраняет свои метафайлы непосредственно в рабочей копии, используя папки .svn. Каждая такая папка имеет записи файла со списком всех каталогов, имеющих тот же уровень, что и соответствующая папка .svn. В папках .svn вы также можете найти информацию о расположении хранилища, размерах файлов, датах изменения и пользовательских логинах . В случае, если вы развертываете свой сайт, просто извлекая рабочую копию в каталог htdocs на веб-сервере, а затем, используя URL site.com/.svn/entries, вы увидите не только файловую структуру проекта, но и список авторов, последние изменения, ссылка на хранилище и т. д.

Вы также можете найти каталог text-base в каждой папке .svn. Он содержит последнюю версию всех файлов, находящихся под контролем версий. Файлы в каталоге text-base имеют расширение .svn-base, что позволяет отправлять его содержимое прямо в вывод браузера, не интерпретируя его на стороне сервера. А именно, позволяет видеть необработанный исходный код !

Тем не менее, есть простые решения этой проблемы.

Apache:

<Directory ~ ".*\.svn">
    Order allow,deny
    Deny from all
    Satisfy All
</Directory>

Nginx:

location ~ /.svn/ {
    deny all;
}

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...