Recientemente leí este artículo: http://www.smashingmagazine.com/2009/09/25/svn-strikes-back-a-serious-vulnerability-found/
Los desarrolladores de muchos sitios populares como apache.org, php.net (http://ru2.php.net/.svn/entries), classmates.com y Yandex ruso usan SVN, pero no siguen las recomendaciones de SVN (para use command de export ).
Entonces, ¿cuáles son las razones para no usar svn export lugar de actualizar la copy pública como todo lo que hacen?
Desde mi perspectiva, lo que hago es bloquear / bloquear el acceso a cualquier file .svn en el server (ya sea Apache2 o IIS) de esta manera las carpetas ocultas no son accesibles externamente, y permite el seguimiento de versiones para los sitios que usamos que no lo hacen requiere comstackr antes del deployment
Idiomas como:
Por lo tanto, puede usar SVN para el desarrollo web, pero debe tener precaución al exponer sus carpetas .svn al mundo si no es prudente. De lo contrario, es una herramienta que podría utilizar para hacer que su trabajo sea más fácil y más eficiente.
Dicho esto, simplemente ejecutamos una SVN UPDATE en nuestra producción para actualizar los files modificados, y con desarrolladores limitados trabajando en un código a la vez (como dije en mi caso) no obtenemos confusiones cuando se implementan cosas incorrectas. . ADEMÁS de estar seguro, siempre haga un SVN CHECK FOR MODIFICATIONS para ver qué se va a actualizar, y oye, si comete un error, vuelva a tirarlo.
Algunas personas, sin include a mí, piensan que para implementar en la producción solo debes emitir un svn up. Si realiza una export, pierde los metadatos sobre el control de versiones para que no pueda hacer eso, tiene que usar otro mecanismo para rastrear qué versión es dónde. Es una solución fácil, pero creo que puede hacer para el empaquetado flojo y también para "fijar en producción", como si hicieras esto, también puedes volver a consultar desde la producción …
Con svn export files de svn export nunca pueden ser eliminados, solo agregados y modificados. Esto podría ser un problema a veces.
Cuando todo el website es de código abierto y está disponible para download a través de un recurso público (como PHP ). Proteger los directorys .svn para que los demás no puedan get el código fuente probablemente no valga la pena sobre simplemente hacer un svn up .