2008-09-25 16 views
8

Necesito personalizar un proyecto de código abierto. Los cambios son para una organización específica y no serán útiles para el proyecto público. Los cambios de código incluyen funciones de deshabilitación no necesarias para la organización (que afectan al 5% del código), personalización de otras características para la organización (que afectan al 20% del código) y adición de nuevas funciones personalizadas (agregando un 10% de código nuevo).¿Cuál es la mejor práctica para bifurcar un proyecto de código abierto?

Podría comenzar con la versión actual y personalizar desde allí. Sin embargo, el proyecto original continúa avanzando e introduce nuevas características, y me gustaría poder incorporar estas mejoras a medida que se presenten.

¿Cuál es la mejor manera de gestionar esto? En este momento, solo puedo obtener versiones de lanzamiento a medida que estén disponibles, pero pronto tendré acceso de solo lectura al repositorio de Subversion del proyecto original. Soy nuevo en el uso de repositorios Subversion, pero también los tengo disponibles para usar con mi código.

+0

¿Es esta una biblioteca o una aplicación de código abierto? ¿Por qué no puedes agregar características a la aplicación existente? –

+0

Interesante [publicación de blog] (http://www.codinghorror.com/blog/archives/001117.html) sobre el tema. –

Respuesta

8

Lo mejor que se puede hacer es no doblarlo. ¿Por qué no averigua cómo mejorarlo para que haga lo que quieres que haga y no pierda ninguna funcionalidad existente? Si el tamaño del código es un problema, tal vez pueda dedicar parte del tiempo que gastaría para mejorar la eficiencia de los proyectos existentes.

+0

@wnoise Lo haré por usted – Cohen

+1

Esto es ideal, pero ¿y si, por alguna razón, las correcciones/mejoras no son aceptadas en la base de códigos tan rápido como lo desea? Si estás trabajando en un proyecto en el que no eres administrador/propietario, esperar cosas como esas a veces no se alinea con los plazos que tienes. Me pregunto si esto es lo que significa el OP. – alph486

0

Importe un volcado de subversión del proyecto original y comience su fork con un repositorio propio como una sucursal: a medida que el proyecto original mejora, puede importar los cambios y luego llamar a 'svn merge' para incorporar estas mejoras. Siempre que usted y el proyecto original no realicen alguna reestructuración (cambiar el nombre de los archivos fuente, moverse entre directorios, etc.), las fusiones deberían funcionar principalmente.

8

La mejor práctica es intentar primero fusionar los cambios en el proyecto.

Si eso no es una opción que acaba de

  1. importar la cabeza actual,
  2. realice las modificaciones en una rama
  3. actualización de su árbol de la de ellos combinación
  4. y rebranch

Los pasos 3 y 4 son relevantes para mantener su bifurcación al día. Es mucho trabajo, dependiendo de la actividad del proyecto y la importancia de mantenerse al día. Si fuera muy importante, actualizaría y fusionaría al menos una vez a la semana.

es posible que prefiera para importar su árbol SVN en git para hacer la fusión fácil, que es lo que va a hacer el más

1

¿Ha hablado con el cable (s) del proyecto? ¿Sus cambios tienen sentido general o son muy específicos para sus necesidades? Si no puede trabajar lo que necesita en el proyecto principal, ciertamente puede ramificar su árbol, simplemente continúe fusionándose sobre la marcha.

Puede buscar en las capacidades de algo como GIT también (que puede interactuar con el svn original muy bien) para aceptar combinación parcial/parche. Cuanto más divergues, más será un problema. Puedes hacerlo con svn y un buen editor, por supuesto, pero tu vida puede ser más fácil con herramientas más flexibles.

3

Creo que poner tus cosas aguas arriba es la manera más segura ya que obtienes todas las correcciones de errores gratis y los cambios realizados aguas arriba no romperán tus cosas ya que otros contribuyentes deben respetar tus "características" también b/c son de primera clase ciudadanos en el proyecto.Si esa no es una opción viable, diría que git con su puente de subversión es el camino a seguir, ya que tiene una gran cantidad de funcionalidades que son útiles para bifurcar, que es la forma natural de hacer cosas en git de todos modos ya que todo es tipo de tenedor de un repositorio diferente.

+1

Absolutamente: Git (o Mercurial u otro DVCS con un puente de Subversion) es una idea mucho mejor para rastrear repos indirectos que Subversion. –

+0

Sí, de todos modos use git-svn para clonar el proyecto. Luego puede usar las poderosas funcionalidades de rebase de ramas de git para mantener actualizados sus cambios. – hlovdal

1

Esta es una variante de la recomendación de Visko, con la suposición opuesta de que pasará la mayor parte del tiempo haciendo sus propios cambios, y solo ocasionalmente integrando una versión nueva del proyecto fuente original. (Usando el vocabulario de Subversion a continuación)

  1. Crear proyecto, confirmar original-source como troncal. Etiqueta.

  2. Al hacer sus cambios locales, utiliza ramas como sea necesario, combinar nuevo en el tronco de la liberación, etc.

  3. Cuando hay una nueva versión de la fuente-proyecto original que desea integrar:

    • hacer una rama para ello;
    • carga (hack) fuente sobre los archivos de ramificación;
    • fusionar la línea troncal en la rama (porque podría llevar un tiempo y no desea romper el tronco);
    • luego fusionar la rama de nuevo en el maletero. Etiqueta.

Ese es el proceso que acaba de diseñar en mi cabeza para mi propio uso. Me encantaría comentarios sobre él.

Cuestiones relacionadas