2009-09-04 13 views
10

Tengo un directorio en un sistema Linux que en su mayoría contiene enlaces simbólicos a archivos en un sistema de archivos diferente. Me gustaría agregar el directorio a un repositorio de Subversion, desreferenciando los enlaces simbólicos en el proceso (tratándolos como los archivos a los que apuntan, en lugar de los enlaces). En general, me gustaría poder manejar cualquier operación de copia de trabajo con este comportamiento, pero el comando 'svn add' está donde comienza, creo.¿Puede el cliente de Subversion (svn) eliminar los enlaces simbólicos como si fueran archivos?

La utilidad del cliente SVN no parece tener ninguna opción relacionada con la desreferenciación de enlaces simbólicos en la copia de trabajo. No encontré ninguna referencia a esto en el manual (http://svnbook.red-bean.com/en/1.5/index.html), tampoco.

me encontré con un cartel en los usuarios de SVN lista que hizo la misma pregunta, pero nunca recibió una respuesta, aquí de correo:

(Eso cartel acabaron utilizando los enlaces duros en lugar de enlaces simbólicos. Esa técnica no es una opción, en mi caso, porque los archivos subyacentes reales residen en un sistema de archivos separado.)

Estoy usando Subversion v1.6.1 en Fedora 11.

Por lo que vale, sé que hay herramientas/técnicas alternativas que podrían ayudar a aproximar este comportamiento, pero que tengo que descartar por varias razones. Ya he considerado [y desempolvado] estas posibilidades: - una montura "unión", que fusiona todos los directorios que contienen los archivos reales, con el directorio de copia de trabajo SVN como la capa "superior" en la unión; - copiando/moviendo los archivos reales al mismo sistema de archivos como la copia de trabajo SVN, y usando enlaces duros en lugar de enlaces simbólicos; - sistemas de control de versiones que no son SVN. Todas estas fueron buenas ideas, y estoy seguro de que son buenas soluciones para otros problemas, pero no funcionarán dadas las limitaciones de este entorno y situación.

+0

Simplemente no creo que eso sea posible (y no creo que ningún VCS pueda hacer esto, sigue los enlaces simbólicos pero no puede rastrearlos, o los rastrea y no sigue). – tonfa

+0

Está empezando a verse de esa manera. Lo cual parece estúpido, dado que la mayoría de las utilidades que manipulan las construcciones de ruta (cp, mv, ln, rm, rsync) tienen todas las opciones para especificar que los enlaces simbólicos deben ser eliminados, no tratados literalmente. Quiero decir, ¿soy solo yo, o la ausencia de una opción de "desreferencia" disminuye la funcionalidad de la herramienta? (Si estoy solo, aquí, probablemente no me molestaré en enviar una solicitud de función al proyecto SVN.) –

+0

3 años tarde, pero no estás solo. Necesito esto también –

Respuesta

1

Tiene muchas limitaciones, pero siempre hay una que funciona: hackear la fuente.

Puedes construir fácilmente tu propio svn para Linux, aunque hacer este mod puede o no ser "fácil". De todos modos, si no tienes enlaces simbólicos gestionados, puedes hacer un truco crudo y simplemente tener svn seguirlos siempre, como si fueran enlaces duros.

Si su repositorio contiene enlaces versionados, y necesita verificar esa parte, necesitará un hack más sofisticado que, por ejemplo, use una propiedad que controle la característica por archivo o por jerarquía o algo.

Puede haber otra opción: los enlaces versionados aparecieron en 1.1.0, si el comportamiento previo a esto era seguir los enlaces simbólicos, entonces quizás podría simplemente ejecutar un antiguo cliente.

+0

Entonces, estás diciendo que la respuesta a mi pregunta real (¿puede hacerlo el cliente de SVN?) Es "no". ¿Derecha? –

+1

Correcto, digo "no, al menos, no desde 1.1.0 y tal vez tampoco antes". Supongo que ha considerado agregar los otros árboles del sistema de archivos y luego simplemente mantener los enlaces simbólicos locales no versionados. Eso parece funcionar muy bien, excepto que se requiere más de una confirmación o actualización para sincronizar toda la copia de trabajo. (Pero no en otras copias de trabajo sin los enlaces locales). – DigitalRoss

0

Idea: inyecte una biblioteca compartida usando LD_PRELOAD que intercepta stat/open/unlink etc. para que svn no vea los enlaces simbólicos. Eso te evitaría tener que modificar la fuente svn.

0

También podría usar enlaces físicos en lugar de enlaces simbólicos.

0

Hasta donde yo sé, con la versión de subversión actual (1.6.x) no hay forma de hacerlo. Si hubiera sido para archivos (no directorios) en el mismo sistema de archivos, podría haber usado enlaces duros (sin el interruptor -s en el comando ln).

0

Me enfrenté a un desafío similar. Mi directorio personal contiene muchos scripts en ~/scripts dispersos en varios subdirectorios. Sin embargo, quería un diseño más limpio en SVN para beneficiar a los compañeros de trabajo que examinan detenidamente cosas que buscan ejemplos de código.

he creado un directorio de ~/scripts/svn/signal15/code/ con prod y test subdirectorios debajo, luego hard-linked todos los guiones dispersos en otros lugares.

El siguiente comando importó el diseño del directorio/archivo que necesitaba;

cd ~/scripts ; svn import svn http://svn_server/repos/code

La cesión temporal muestra ahora http://svn_server/repos/code/signal15/ con "prod" y "prueba" sub-directorios.

Ahora tengo diseños personalizados; a) El diseño de mi directorio personal no se modifica (sans ~/scripts/svn subdirectorio) b) El repositorio SVN contiene una rama "signal15" con mis scripts organizados. P.S: con una función de shell, también puedo hacer el check-in y check-out si es necesario.

Cuestiones relacionadas