TODOPIC
Misceláneas - Interés General => Off Topic => Mensaje iniciado por: JBQ en 07 de Mayo de 2012, 06:58:00
-
Hola, de seguro esto también les ha pasado a alguno de ustedes, y sino es asi... :oops: OK... a mi me esta pasando.
Resulta que muchas veces cuando desarrollamos nuestros firmwares para nuestros proyectos, nos vemos en la necesidad de hacerle una mejora, o una corrección o modificación para que trabaje con un nuevo circuito. Es en estos casos donde empieza a producirse una especie de embrollo, necesitando en algún momento regresar a un punto anterior a esa modificación, y si no se sigue un orden, pues uno se pierde.
Para esto yo idee un sistema propio, donde versiono a mis firmwares siguiendo simples criterios. Pero, resulta que a veces aparecen casos en los que mi sistema se cae o no es lo suficientemente ideoneo para resolverlo. Por eso acudo a escuchar algunos consejos de personas que de seguro puedan orientarme con esto. Sé que esto va por el lado mas personal de uno, pero nunca esta de mas escuchar los sabios consejos de la experiencia.
Saludos.
-
Hola, yo trabajo agregandole un número al final, y de manera creciente, colocando todos los agregados ,mejoras o correcciones en los REM del encabezado. Pero siempre trabajo en el que no tiene ningún número en el final... por lo cual, éste, siempre es mi ultima versión....
Supongo que hay otras opciones... :mrgreen:
-
Hola
Yo uso x.y.z
x es la versión principal
y es la mejora importante que he agregado a tal versión
z es un cambio menor que he hecho
Siempre empiezo en la 0.1.0 y de ahí para arriba.
Si hago una copia de una versión que no sirve, le llamo broken y la dejo guardada por si hace falta en el futuro.
-
En el software profesional se utilizan cuatro números. Los tres primeros son los que ha definido migsantiago y el cuarto es el número de compilaciones (este número se incrementa de forma automática cada vez que lanzamos la compilación), puede que debido a pequeños bugs no sea necesario cambiar el núemro de versión del firmware y sería suficiente con los cambios en el número de compilación. Por ejemplo mi antivirus (Kaspersky es 6.0.4.1424).
Un saludo
-
Hola y muchas gracias por sus consejos.
Yo también documento todo en el encabezado como lo hace TODOPIC, pero aplicando el sistema de X.Y de migsantiago (sin la Z claro, pero creo que voy a tener que implementarla); y aún asi he tenido complicaciones.
Por ejemplo: una vez estaba desarrollando un firmware que controlaba unos 4 reles y un LCD. Yo estaba agregando un número por cada función que añadia. Ya estaba por la V.1.6 y todo iba bien... hasta que el cliente me pide que ya no sean 4, sino solo 1 rele. Entonces yo dije: sera la V.1.7 (no altere ni la PCB ni la versión por que considere que el cambio era mínimo) y segui avanzando. Luego me pide un nuevo cambio, pero esta vez del menu del LCD. Esto me puso en la necesidad de alterar mi orden asi que yo dije... sera la V.1.71. Pero todo se complicó cuando me dijo que ahora quiere los 4 con ese menu, y yo... :shock:... no sabía si regresar a la V.1.6 y continuar renombrandolo; o cambiar a la V.1.8
Creo que esto se solucionaria, analizándolo bien, si usara desde un comienzo el método V.X.Y.Z; pero que pasara cuando el cambio al firmware requiera una mezcla de la versión Y con la versión Z ???
-
Te recomendaría que usaras, además de escribir en algún lugar el changelog, un sistema de control de fuentes.
Yo lo tengo instalado (uso Subversion) y en su repositorio van a parar todas las versiones desde la 1.0.0.0, y cuando hago un release le aplico un TAG, luego si voy a hacer un retrabajo abro un branch y el head queda intacto, luego el sistema me permite hacer el merge.
saludos.
P.D.: Puedes leer sobre subversion en la wiki
http://en.wikipedia.org/wiki/Apache_Subversion
Está disponible para linux y window$
-
Ok Felixls; me parció interesante tu propuesta (aunque al comienzo no la entendi mucho) y me puse a investigar sobre ello. La cara que puse cuando por fin encontre utilidad a esa opcion del menu del mplab.
Veo que esta parece ser la solución a mi problema, asi que me decidi a probarlo. Pero, estoy en duda sobre cual de estas 2 posibilades usar: CVS o SVN (subversion). Lamentablemente toda la información que encontre sigue siendo referente a softwares, asi que si no es mucha molestia, te pediría por favor una recomendación de cual de los 2 usar, o porque usas SVN y no CVS... saludos.
-
CVS es anterior a SVN, este último soporta transacciones y son atómicas, está pensado para usarse en conecciones http por webdav, su rápida base de datos relacional de los fuentes (FSFS) y motor fue reescrito y mejorado en varios años de desarrollo, etc.
En resumen, te recomiendo SVN.
saludos.
-
Muchas gracias por la info felixls, seguire tu recomendación. Solo una últiima cosa más: es realmente necesario usar un servidor para los repositorios?, por que mi intención es usarlo solamente en mi maquina y únicamente por mi, y la verdad todas las paginas que encuentro solo dan guias de como instalar con servidor apache, con servidor dropbox, etc etc.
-
Lo puedes instalar de manera local, usa VisualSVN server por ejemplo
(http://www.todopic.com.ar/foros/index.php?action=dlattach;topic=38266.0;attach=18535)
http://www.visualsvn.com/server/
(Es gratis en un contexto de workstation)
-
mmm ya veo. Muchas gracias por el dato felixls... saludos.
-
Cual me serviria para trabajar con PICC ??
-
Que sería PICC?
-
El compilador C de CCS. :mrgreen:
-
Si el IDE de CCS no tiene soporte de SVN lo que se puede hacer es usarlo integrado al Windows Explorer con TortoiseSVN
http://tortoisesvn.net/
-
Hola
y el MPLAB si lo soporta?
Saludos
-
MPLAB lo ignoro, MPLABX seguramente si.
-
Bueno, retomando el tema...
MPlab V.8.x lo soporta, y también CVS y Visual Sourface.
El MPLabX también lo soporta, y también CVS y mercurial, pero SVN tiene algunos problemas, asi que es mejor trabajarlo con el TORSTOIESVN.
Bueno, luego de probar tanto SVN como Hg; (el Hg no tanto, más el SVN), pues termine muy instruido en lo que debe de ser la organización de mis proyectos, pero lamentablemente la solución particular que yo buscaba no me la proveía. El SVN no versiona, solo organiza muy bien los proyectos, es la conclusión que pude sacar. Probe con el mplab y con un simple archivo TXT; y nunca obtuve un 1.1 o 1.2, simpre era 1 luego 2 luego 3, y asi sucesuvamente por cualquier cambio o actualización que hacía (commit) aumentaba en un digito la revision, ya sea un tag o un branch.
Bueno pues, parece que los programadores de softwares la tienen facíl en ese aspecto, ya que su compilador se encarga de eso... jejeje.
Volvere al metodo anterior que tenía, pero con las recomendaciones de los primeros post.
AHH, por cierto, lo probe en asm con el mplab. Tendrá eso que ver con la crudas revisiones (1 2 3... y no 1.1 1.2 1.2.1 ....) que me daba el SVN???