Software de 2 versiones: ¿el mejor enfoque VCS?

Question

supongo que será mejor que explique mi situación:

Estoy en el proceso de desarrollar algún tipo de software, y estoy en la etapa en que me gustaría dividir mi proyecto en dos ramas que difieren en características . Sucede que esta aplicación es una aplicación de Android que implementaré en Market, que tiene la limitación de que cada aplicación debe tener un identificador de paquete único (sensible, ¿no?).

Mi enfoque actual ha sido clonar el git repo de mi proyecto original, pero esto causa problemas con los nombres de los paquetes. Quiero que el sistema sea lo suficientemente robusto para que una corrección de errores/nueva función en una rama se fusione en otra rama, pero solo cuando yo quiera.

¿Alguien tiene alguna sugerencia?

Answer 1

Manejo esa misma caja para una aplicación de pago y una versión de prueba que tienen la misma base de código. Estoy usando SVN, pero cualquier software de control de versiones que admita la ramificación funcionaría.

Creé una rama para la versión de prueba desde el maletero.

Luego modifiqué el AndroidManifest.xml de trial verion para cambiar el nombre del paquete, agregando .trial al final. Luego tuve que actualizar todos los archivos java de actividad para hacer referencia a la clase R correcta.

Mi paquete de aplicación de pago es com.hewittsoft.baby
Mi paquete de la aplicación de prueba es com.hewittsoft.baby.trial

En mis actividades en la rama de prueba que hago esto

import com.hewittsoft.baby.trial.R; 

y eso hace que todas las referencias a R.id.textField (o lo que sea) funcionen.

Después de hacer esos pasos puedo desarrollar en la rama principal y luego fusionar cualquier cambio en la versión de prueba sin demasiado dolor.

Answer 2

Si el único problema es un problema de administración de paquetes y lanzamientos, puede aislar esos pasos (cambiar el nombre del paquete y probarlo en un entorno de destino) del ciclo de historización dentro de un repositorio de Git.

De modo que podría continuar, separar su desarrollo, una función por rama, manteniendo los mismos nombres de paquete para ambos (con el fin de combinar fácilmente las correcciones de una a otra).
Pero luego, para probar e implementar una de esas dos versiones, podría tener un script a cargo de renombrar los paquetes, recompilar, empaquetar (jar) e implementar el resultado en el entorno de prueba de destino.

Answer 3

Un par de muy buenos artículos sobre estrategias de ramificación: http://codicesoftware.blogspot.com/2010/03/branching-strategies.html http://nvie.com/git-model