Nombre en vez de numeración en versiones

[dec]

Hola,

Yo reconozco que no usar control de versiones en todos mis proyectos me cuesta más de un dolor de cabeza. Desde hace tiempo incluyo la fecha en las versiones de mis programas. La cosa es que suelo actualizarlos con mucha, quizá demasiada frecuencia, y así no cambio de versión (1.0) pero sí de fecha. Así los archivos "historial" de mis programas contienen títulos como "1.0 (08/29/2005)". Y más abajo puede haber otro título tal que "1.0 (08/27/2005)".

Tengo para mí que no es la mejor manera de hacer las cosas. Reconozco que no he pensado muy seriamente en ello. Creo que números de versión como los que menciona Azidrain arriba podrían estar bien. Respecto de nombrar las versiones, me temo que alguna vez he caído en la moda, puesto que así lo he visto yo con mis cortas miras. Algunos proyectos los nombré o nombré sus versiones, pero, actualmente no lo hago.

[mamcx]

Usar mercurial es muy facil (en comparacion con git) y su uso es tan bueno para proyectos solos como acompañados por otros. Yo aprendi con

http://hginit.com/

Y uso esta herramienta de forma visual (aunque casi todo lo hago en el terminal, para caso mas avanzados, para hacer diff y resolver conflictos es muy util):

https://www.sourcetreeapp.com/

[Casimiro Noteví]

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 Noteví]

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 Noteví]

Empezado por AgustinOrtu

Tortoise Git

Gracias, voy a echarle un vistazo

[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