Pregunta

El concepto subversivo de ramificación parece centrarse en crear una bifurcación [inestable] de todo el repositorio sobre la cual realizar el desarrollo.¿Existe un mecanismo para crear ramas de archivos individuales?

Para un caso de uso, piense en un archivo de encabezado común (*.h) que tenga múltiples implementaciones de fuente (*.c) específicas de la plataforma.Este tipo de sucursal es permanente.Todas estas ramas experimentarían un desarrollo continuo con fusiones ocasionales entre ramas.Esto contrasta marcadamente con las ramas de desarrollo inestable/lanzamiento estable que generalmente tienen una vida útil finita.

I no desea bifurcar todo el repositorio (barato o no), ya que crearía una cantidad irrazonable de mantenimiento para fusionar continuamente entre el tronco y todas las ramas.Actualmente estoy usando ClearCase, que tiene un concepto diferente de ramificación que lo hace fácil.Me pidieron que considerara la transición a SVN, pero esta diferencia de paradigma es importante.Estoy mucho más preocupado por poder crear fácilmente versiones alternativas para archivos individuales que por cosas como cortar una rama de versión estable.

¿Fue útil?

Solución

Lamentablemente, creo que la verdadera respuesta aquí es que ClearCase maneja esta situación mucho mejor que Subversion.Con la subversión, hay que ramificarse. todo, pero ClearCase permite una especie de idea de "rama diferida" que significa que solo se bifurca un determinado grupo de archivos, el resto sigue el tronco (o cualquier rama que especifique).

Las otras soluciones proporcionadas aquí realmente no funcionan como usted desea, simplemente copian el archivo a una ruta diferente.Ahora tienes que hacer cosas extrañas para usar ese archivo.

Emmm, lo siento.Esa no fue realmente una muy buena respuesta.Pero no existe una buena solución para esto con Subversion.Su modelo es bifurcar y fusionar.

Editar:Bien, ampliando lo que dijo crashmstr.Podrías hacer esto:

svn cp $REP/trunk/file.h $REP/branched_files/file.h
svn co $REP/trunk
svn switch $REP/branched_files/file.h file.h

Pero ¡guau!, eso es propenso a errores.Siempre que hagas un svn st verás esto:

svn st
    S  file.h

Un poco ruidoso eso.Y cuando desee bifurcar algunos archivos o módulos dentro de un repositorio de código grande, comenzará a ser muy complicado.

En realidad, probablemente haya un proyecto decente aquí para simular algo como los archivos ramificados de ClearCase con propiedades svn y conmutación, escribiendo un contenedor alrededor del cliente svn estándar de bog para lidiar con todo el desorden.

Otros consejos

No es necesario ramificar todo el repositorio.Podrías crear ramas de carpetas en tu proyecto (como una carpeta de inclusión).Como otros han señalado, también puede hacer una "copia" de un solo archivo.Una vez que tenga una copia de un archivo o carpeta, "cambie" al archivo o carpeta ramificado para trabajar en la versión ramificada.

Si crea una carpeta de ramas separada en el repositorio, puede copiar sus archivos ramificados allí mediante comandos del lado del servidor:

svn copy svn://server/project/header.h svn://server/branched_files/header.h

Entonces podrías cambiar ese archivo para usar el branches_files ruta del repositorio

Así es como entiendo tu problema.Tienes el siguiente árbol:

time.h
time.c

y debes rechazarlo para múltiples arquitecturas:

time.h is comon
time.c (for x386), time.c (for ia64), time.c (for alpha),...

Además, en su VCS actual puede hacer esto creando tantas ramas desde time.c como sea necesario y cuando retira los archivos del VCS, verifica automáticamente el último time.h del tronco común y el último time.c de la rama. estás trabajando.

El problema que le preocupa es que si usa SVN al verificar una rama, tendrá que fusionar time.h desde la troncal con mucha frecuencia o correrá el riesgo de trabajar en un archivo más antiguo (en comparación con la troncal), esa cantidad de sobrecarga no es aceptable. A usted.

Sin embargo, dependiendo de la estructura de su código fuente, podría haber una solución.imagina que tienes

 
/
/headers/
/headers/test.h
/source/
/source/test.c

Entonces podrías bifurcar / y usar el svn: externos Característica para vincular sus encabezados a la cabeza del tronco.Solo funciona en directorios y tiene algunas limitaciones con respecto a la confirmación de test.h (debe ir al directorio de encabezado para que funcione), pero podría funcionar.

Una "rama" de Subversion es solo una copia de algo en su repositorio.Entonces, si quisieras bifurcar un archivo, simplemente harías:

svn copy myfile.c myfile_branch.c

¿No creo que tenga mucho sentido ramificar un solo archivo?¿No hay forma de probarlo con el código troncal?

En su lugar, puede utilizar un parche si desea deshacer los cambios y aplicarlos más adelante.

¿Estás seguro de que realmente necesitas esta función? en tu VCS ?

¿Por qué no utilizar el preprocesador C y #ifdef eliminar el código que no necesita?O cualquier herramienta similar.

algo como:

// foo.h:
void Foo();

// foo_win32.c
#ifdef _WIN32
void Foo()
{
   ...
}
#endif

// foo_linux.c
#ifdef _GNUC
void Foo()
{
   ...
}
#endif

A veces, si no encaja bien, entonces no es la solución adecuada.

Una sucursal en SVN es solo una copia.Creo que para hacerlo de la manera que espera, deberá tener cada versión del archivo en un directorio separado en el repositorio y verificarlo en su carpeta de origen.ES DECIR.Trate ese archivo como un proyecto separado.

Una rama en Subversion es exactamente de lo que estás hablando.Todos los archivos son una copia exacta del baúl, a excepción de los que cambias.Esta es la metodología de "copia barata" de la que se habla en el Libro SVN.La única advertencia es la necesidad de fusionar el tronco con la rama de vez en cuando para asegurar que los cambios realizados allí se reflejen en la rama.Por supuesto, si no se desean esos cambios, no es necesario realizar fusiones troncal->rama.

Una forma sencilla de permitir que los cambios de la troncal se fusionen automáticamente (lo que simula el paradigma Clear Case) sería utilizar un script de enlace previo a la confirmación para fusionar los cambios de la troncal antes de la confirmación (de hecho, esto siempre es una buena estrategia para evitar la deriva del código).

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top