Nombre en vez de numeración en versiones

[Casimiro Notevi]

Yo he usado varios, el último fue jedi vcs, porque se integraba dentro del propio delphi. Y resultaba muy cómodo.
Ahora no sé qué usar, no encuentro la forma de hacer algo "simple". Me explico: yo solo, varios proyectos, cada proyecto puede tener varias versiones y, lo principal, cada versión puede tener varios ficheros adaptados para distintos clientes.
Quisiera poder elegir algo así como: proyecto xxx del cliente yyy, y que si modifico algo del proyecto xxx se actualice en el de todos los clientes de ese proyecto. Pero si un cliente tiene un fichero adaptado para él, que esos no se cambie lo que esté adaptado para él, solamente lo que es genérico para todos.

[[AgustinOrtu]]

Empezado por Casimiro Notevi

Quisiera poder elegir algo así como: proyecto xxx del cliente yyy, y que si modifico algo del proyecto xxx se actualice en el de todos los clientes de ese proyecto. Pero si un cliente tiene un fichero adaptado para él, que esos no se cambie lo que esté adaptado para él, solamente lo que es genérico para todos.

Yo lo hago con git y las llamadas branch:

Por defecto se crea una branch master en donde esta el proyecto llamemos "principal"
Luego por cada cliente que tiene una modificacion particular, se crea un branch a partir de una existente, por ejemplo de master.

Entonces ahi en esa branch es en donde haces las modificaciones para "pepito" y el resto ni se entera. De hecho al andar pasando entre un branch y otra (git switch branch) lo que realmente sucede es que los archivos con los que trabajas localmente pasan a ser los de la branch a la que cambiaste

Ej: Estabas en "pepito", haces switch a "master" y todo lo que agregaste nuevo en pepito no va aparecer en el disco fisicamente. No vas a tener un NuevoFormAgregado.pas. Logicamente si volves a pepito si va a estar. En ese sentido se mantiene la estructura simple y no tenes que andar comiendote la cabeza pensando "esto era de quien???"

Lo unico que no es automatico es el tema de, llamemosle "herencia". Para que se propagen los cambios es necesario hacer merge/cherry pick. Es decir, "alimentarte" de todos los nuevos cambios (commits) que queres que se reflejen. Esto lo tenes que hacer en CADA branch; podes pickear commits de cualquier brach, incluso de otro repositorio

[Casimiro Notevi]

Empezado por Al González

...

Sí, Al, gracias, más o menos es lo que hago, aunque no resulta muy eficiente con distintos parámetros para mantener el código para un cliente u otro. Pero no he encontrado nada mejor hasta ahora. Saludos
PD. Por cierto, no es con Delphi, desde hace unos años estoy haciendo "cositas" para Android. Cosas de la vida, que te lleva de un lado a otro y todo cambia por completo cuando menos te lo esperas.

Empezado por AgustinOrtu

...

Lo que comentas parece interesante, pero todos los sistemas de control de versiones que he visto me resultan engorrosos para mantener varios proyectos con distintas versiones y distintas subversiones, ¿usas algún entorno gráfico para usar Git o todo mediante comandos?

[[AgustinOrtu]]

Tortoise Git

[Casimiro Notevi]

Empezado por AgustinOrtu

Tortoise Git

Gracias, voy a echarle un vistazo

[[Al González]]

Acá usamos TortoiseSVN para administrar los archivos desde el explorador de Windows. Somos un equipo de cuatro personas, todos con sus ideas muy arraigadas. Lo más difícil ha sido ponernos de acuerdo en cómo llamarles a los directorios.

[mamcx]

Empezado por Casimiro Notevi

Lo que comentas parece interesante, pero todos los sistemas de control de versiones que he visto me resultan engorrosos para mantener varios proyectos con distintas versiones y distintas subversiones, ¿usas algún entorno gráfico para usar Git o todo mediante comandos?

La facilidad de hacer branchs (y Merges, que es lo dificil!) es la habilidad #1 de git/mercurial. Es muy facil la mayor parte del tiempo, y si puedes lograrlo como dice * AgustinOrtu* es lo mejor...

Ahora bien, tambien se puede usar un "mono-repo"

http://danluu.com/monorepo/

Que es meter todo los proyectos en un solo repositorio. Curiosamente, asi hacen en facebook y otras empresas donde todos los proyectos estan en un solo lugar. Obvio, descargar eso puede implicar una *larga descarga* inicial, pero es cuasi-identico a cargar una "directorio de proyectos portable", y sigues haciendo tal cual como hasta ahora.

----

Si la cosa es muy complicada, tienes un problema de dependencias muy severo, entonces tienes un problema de programacion: Debes desacoplar el codigo, y hacer composicion y eliminar herencias. Muchos no lo ven, pero le relacion de los archivos en un proyecto (modulos, namespaces) TAMBIEN hace parte del arbol de objetos, y cuando estos dan lios? Es porque hay una falla en el diseño de ese arbol ==== Tal cual como hay una falla en un arbol OO o en la construccion de Tablas en una BD.

"Plano es mejor que anidado"
"Simple es mejor que complejo, y complejo que complicado"
"Prefiere composicion en vez de herencia"
"Principios SOLID para proyectos OO"
"Elimina el manejo de estado no esencial"

Y mucho mas tambien aplica...

[[AgustinOrtu]]

La mejor forma de hacer merges o cherry pick es evitar commit estilo

Commit hash xxxxxzzz:
Agrego al cliente método bla bla
Corregido listado de bla bla
Nuevo campo en la BD bla bla

Lo mejor es ser ordenado y hacer un feature por commit/commit lo más sencillo posible que toque lo menos archivos posible

Haciendo eso los merge son cuento de niños