[safa] ¿Que es lo que esta pendiente?
Dario Rodriguez
Como a veces es poco visible lo que se hace y lo que no, estoy tratando de usar estos mails 'sumario' sobre el desarrollo en la cocina, y lo que nos queda pendiente. Esta es la lista de cosas que tenemos por hacer:
+ safa-commit : Este lo estaba viendo yo. Con esto iriamos cerrando una etapa.
+ safa-check-from-commit: El que lo quiera tomar para hacer es bienvenido. Seria similar a la funcionalidad de "safa-diff-from-tree", dejandolo cuasi obsoleto (por ahora). el check-from-commit sería la operación que compara el SHA-1 de un archivo contra el SHA-1 que tenía en un determinado COMMIT. Para eso abre el COMMIT, verifica que no sea abstracto, lee el TREE al que hace referencia, usa safa-cat-tree para leer el TREE, y busca en el mismo la linea que contenga ese archivo. Esa linea tendrá un SHA-1 que corresponde al archivo como estaba en ese COMMIT. Luego se calcula el SHA-1 actual del archivo. Si el archivo es igual, retorna 0, si es distinto, retorna 1. Esto a menos que se le especifique el flag --perm, con el que tendrá que verificar que los permisos sean iguales, y lo mismo: Si son distintos devuelve 1. Para mi es muy útil hacerlo en shell, o en perl, que también puede hacer uso del backtrick para llamar comandos. Debe considerar que se le puede pasar una referencia directa. Una referencia directa es un archivo en '.safa/refs' que tiene el nombre de un COMMIT. Después habrá otras referencias, pero las manejaremos con la API.
+ safa-tree-from-index: Sobre esto, Nico ya pasó unos cambios. No tengo tiempo ahora de verlos, pero prometo agarrarlo esta noche o mañana así te comento algo, y lo ponemos para todos.
+ safa-addfiles: Me falta modificarlo un poco, y habria que usar safa-check-from-commit para que verifique por referencia con HEAD, así sabremos si el archivo cambió y debe ser agregado, o no.
+ safa-initrepo: Tambien debe traer de la configuración global los parámetros user.name y user.email. Una vez hecho, se tienen estos parámetros para safa-commit.
Con esto tenemos cubiertas las operaciones para versionar inicialmente, y de forma totalmente LINEAL:
safa init -> safa-initrepo : inicializa el repositorio, importa configuración
safa add -> safa-addfiles : agrega archivos al INDEX (addindex)
-> safa-check-from-commit
safa status -> safa-status : muestra el estado del INDEX (archivos cambiados, etc...)
-> safa-check-from-commit
safa commit -> safa-commit : crea el TREE con los cambios, agrega el COMMIT
-> safa-check-from-commit (?)
-> safa-tree-from-index
Luego hay que crear safa-revlog para poder hacer el log del historial.
En paralelo, me complace anunciar que, ya que tenemos bastante funcionalidad bien definida, comenzaremos a codificar la API en C. Para esto, cuento con Alfredo y el que quiera sumarse. En cuanto pueda voy escribiendo lo que será nuestro standard de codificación, o de aceptación del código.
Saludos
--
Dario
Dario Rodriguez
> Si tree-from-index ya estaria, me gustaria agarrar check-from-commit,
> asi voy entendiendo mejor.
> Con respecto al lenguaje, si bien a simple vista coincido que puede
> ser C, me permito preguntar, por que C y no otro? Es una cuestrion de
> preferencia, o realmente agrega alguna ventaja?
> Obviamente tb me sumo a escribir la API
>
Pongo en copia a la lista porque es interesante la pregunta.
C es mi preferencia, cualquiera que me conoce lo sabe, pero lo es
precisamente porque agrega ventajas.
Cuando nos proponemos hacer la biblioteca definitiva buscamos algunas
ventajas que no teníamos con los borradores. Lo que no necesariamente
buscamos: Código rápido (para eso usabamos borradores). Lo que si
buscamos: velocidad; mucho más control del que podíamos tener con
Bash, por ejemplo; y la capacidad de hacer algo pulido y limpio. Por
otro lado, estamos escribiendo una Biblioteca, y eso significa
escribir el layer más bajo, para que pueda ser de uso general.
Esta última ya es motivo suficiente para elegir C, porque así
cualquiera puede usar las funciones desde GTK, Python, Perl, Ruby,
C++, Qt, etc, etc...
Alguien puede hacer un wrapper en C++, pero accediendo directo a las
funciones del core en C, para guardar coherencia y velocidad. Años
usando C++ y años usando C (y usando Perl, y usando bash, y usando
Linux, y FreeBSD) me enseñaron que esta es la metodología más sana (en
juego con el inglés 'sane').
La velocidad, el control, y sobre todo, la simpleza de las tablas de
símbolos y los procesos de depuración decantan todos en la elección de
un lenguaje que se relacione de forma directa con el SO y tenga una
filosofía de simpleza y claridad: C
Si alguien considera que C es complicado, es obvio que necesita
experiencia en el lenguaje. Si consideran que es lento, es obvio que
consumieron ácido lisérgico y tienen alteraciónes de la percepción del
tiempo. C es un lenguaje claro, con el que adquirimos el total control
del programa, con la ventaja de que, al modularizar de forma correcta,
cualquier newbie en el proyecto puede entender lo que hace una
determinada función sin conocer totalmente el entorno. Y con la super
ventaja de que todo en UNIX está hecho para interactuar con C.
Saludos
--
Dario
Nicolas Palumbo
general no es de mi preferencia, lo uso poco y nada, pero se como
usarlo digamos.
La idea era mandar la pregunta a la lista y que sea usada como un
puntapié y que todos los otros se sumen en la discusión. De manera
que todos se sientan cómodos con este tipo de decisiones. Que no son
locales a un solo modulo sino que definen el futuro del proyecto y
ademas son de ser irreversibles una vez que el código adquiere cierto
tamaño y actividad.
2011/12/5 Dario Rodriguez <soft....@gmail.com>:
Alfredo Gore
Siendo el proyecto orientado a sistemas Unix/Unix-like parece la eleccion mas logica. Igual me parece que por ahora las propuestas estan abiertas, ya que solo estan los borradores en shell script.
Saludos.
--
--------------------
Recibes esto porque estas suscrito a "safa-dcs" en GoogleGroups.
Puedes enviar correo a: safa...@googlegroups.com
Para desuscribirte, envia un correo a: safa-dcs+u...@googlegroups.com
Mas info: http://groups.google.com/group/safa-dcs
S.A.F.A. - More than just version controlling
Dario Rodriguez
Pero cuando hablamos de transferir esas funcionalidades a una biblioteca, debemos tener en cuenta que esa API debe ser lo más generica posible, a demás de rápida y super controlada en términos de seguridad:
Un árbol de precedencia de lenguajes e interfaces para escribir APIs iría así:
ncurses <-- C --> GTK+
_______________|______________
/ / | \ \
C++ Perl Python Ruby PHP
| | __|__ |
Qt PerlQT / \ Interfaces WEB
PyQT PyGTK
Lenguajes más, lenguajes menos. Realmente una API en UNIX debe estar en C. A partir de ahi se pueden hacer interfaces ncurses, GTK+, wrappers C++, modulos Perl y Python, extensiones RUBY, etc...
Normalmente este es un punto que se da por sentado en un proyecto para hacer una biblioteca en UNIX (hablo de sistemas Unix-like o familiares).
El que no guste de C, puede expresarnos sus ideas en Python, o algun lenguaje similar, y nosotros evaluaremos si es necesario incluirlo a la API (costo/beneficio, etc...).
Saludos
--
Dario