elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: Guía rápida para descarga de herramientas gratuitas de seguridad y desinfección


+  Foro de elhacker.net
|-+  Programación
| |-+  Programación General
| | |-+  [proyecto] Nuevo controlador de versiones
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] Ir Abajo Respuesta Imprimir
Autor Tema: [proyecto] Nuevo controlador de versiones  (Leído 1,956 veces)
D4RIO


Desconectado Desconectado

Mensajes: 1.004


U N I X


Ver Perfil WWW
[proyecto] Nuevo controlador de versiones
« en: 11 Noviembre 2011, 16:00 pm »

Hola Foreros,

Solamente paso para escribirles sobre un proyecto que estoy empezando. Tras bastante tiempo de uso de GIT, hay algunas cosas que me planteo diferentes. No es porque GIT sea malo, ni quiero volver esto una discusión sobre la necesidad de otro controlador de versiónes.

Se que muchos aficionados a Shell, C y Perl, pueden estar entusiasmados por trabajar en un proyecto así, y espero llegue a ser competente.

Quienes sepan trabajar en equipo y de una forma respetuosa, son bienvenidos.

Escriban MPs y/o correo a soft.d4rio (en) GMail para recibir alguna instrucción sobre qué hacer.

Saludos

PD: El proyecto se escribe en inglés, aunque la organización de las tareas la estoy haciendo en castellano. Cualquiera puede participar porque siempre habrá alguien dispuesto a traducir y explicar.


En línea

OpenBSDFreeBSD
Littlehorse
All the world's a stage
Colaborador
***
Desconectado Desconectado

Mensajes: 2.714


Nie Dam Sie


Ver Perfil WWW
Re: [proyecto] Nuevo controlador de versiones
« Respuesta #1 en: 15 Noviembre 2011, 23:40 pm »

Estaria bien un overview del proyecto a modo descriptivo para que esto no quede solo como un aviso.

Me parece muy bien el proyecto, es real que se necesita algo mejor y quien sabe puede salir de aca.

Saludos!


En línea

An expert is a man who has made all the mistakes which can be made, in a very narrow field.
D4RIO


Desconectado Desconectado

Mensajes: 1.004


U N I X


Ver Perfil WWW
Re: [proyecto] Nuevo controlador de versiones
« Respuesta #2 en: 17 Noviembre 2011, 14:03 pm »

A ver, algo de información...

Por ahora le puse SAFA, no se si vaya a quedar así, pero me sonó bien y viene a "Simple-And-Fast-Alternative", y da juego a "Simple and fast alternative VCS", etc... el resto, por lo pronto pensé varios conceptos, varias ideas, todos a discutir y flexibilizar para que sea lo mejor según todos y para todos (o la gran mayoría):

Que haga lo que debe:
Mi idea principal es enfocarme en lo que queremos que haga bien. La filosofía UNIX es lo primero (simplicidad y modularización), lo segundo es "¿es sensato aplicarlas a este caso?", y la regla para elegir entre 1 y 2 es la de la menor sorpresa. Lo mismo para las features y elecciónes. Si una funcionalidad no primaria en cuanto a nuestros objetivos interfiere con una primaria, no se hará, o se pondrá como opcional, a menos que eso determine la utilización más intuitiva.

En distributed VCS, el historial es un concepto LOCAL:
Simplemente eso. A cualquiera le cansa la necesidad de estar horas descargando el kernel de LINUX via GIT ¿Porque querría yo tener el desarrollo de LINUX desde que debutó en el repo de GIT? Es realmente tedioso saber que gran cantidad del tiempo y espacio en disco perdido es para cosas que no vas a utilizar... NUNCA. Mi idea es un historial donde podamos adjuntar o desprender partes antiguas, quizá almacenarlas, quizá no.

Las buenas operaciones no se ponen en un programa, se ponen en una API:
La idea es tener una buena API en C, un wrapper en C++, y de ahi a Ruby, Python, etc... para que programar sobre la base del core del versionador sea sencillo sin importar en que programes. Uno no tiene porqué hacer una horrenda cañeria con PIPES para trabajar con el versionador. El concepto de plomería debería ser un poco más refinado que eso.

La sincronizacion es una buena idea, pero es mejor la actualización asíncrona:
Me ha pasado, en GIT, que no puedo hacer una sincronización via "clone", "push", "fetch", etc... por temas de red. Cuando esto pasa, nos sentimos tentados a enviar un patchset. El problema es que de esta forma los commits ya no conservaran el SHA-1, porque al aplicarse un parche se hace un nuevo commit. Poder empaquetar una sincronización es ilusorio, porque sincronizar requiere trabajo de ambas partes, pero la actualización asíncrona es algo factible. Podemos empaquetar una actualización desde el commit A al B, y dejarla guardada, enviarla por e-mail, etc, sin destruir el contenido exacto, y por lo tanto las huellas criptográficas del historial.

Los commits no son los cambios reales:
Los commits son piezas de información referentes a un árbol, que nos ayudan a comprender lo que ha cambiado respecto al anterior, son partes del log. Entonces podría anidar commits para sumarizar información en niveles. Hablando del modelo ITIL, un release puede incluir varios cambios, algunos grandes y otros chicos. Si el log fuera como nuestro "changelog", podríamos mejorarlo haciendo que se puedan anidar los cambios grandes como muchos commits dentro de un commit, entonces los 2 niveles pueden expandirse, hasta que llegamos a los commits que apuntan a los árboles. Esto me indica que puedo ver la información en perspectiva, "granulada" o no.

La decisión de cómo almacenar es un concepto local:
Un usuario puede preferir hacer un blob nuevo cada vez que cambia un archivo, o puede decidir grabar diffs entre release y release. Estas decisiónes influiran en la velocidad de checkout, el consumo de disco, etcetera. Al armar un paquete de sincronización, siempre se elegirá hacer deltas para disminuir la cantidad de información enviada, así que el almacenamiento queda como una elección para el usuario.

A demás, un sistema distribuido con un un repo central puede configurarse para ser (pseudo)centralizado, donde se agregan acciones de bloqueo y desbloqueo, con varias metodologías posibles, desde privilegios hasta autobranching (esa palabra la acabo de inventar, pero creo que se entiende).


Aunque hay muchos más, la rigidez en conceptos no es compatible 100% con el desarrollo en grupo.

Por ahora estoy usando GoogleGroups y Trello, que me parece práctico, pero estoy prácticamente solo. Hice algunos scripts de shell (bash) aunque planeo que todo el core termine siendo traducido a C inicialmente para la API y luego llevada esta hacia el programa.

Deje el ultimo fuente en trello, pero se puede usar GIT hasta que SAFA sea capaz de auto-hospedarse.

Como para que se copen, les dejo algunos pedazos de código que pueden ver, uno es la biblioteca de funciones del shell, que es sencilla y les permitirá ver algunas de las premisas que tengo para programar:
Código
  1. # DEBUG FLAG: 0/1
  2. test -z $DEBUG_ && DEBUG_=0
  3.  
  4. DEBUG() {
  5. test $DEBUG_ -eq 1 && $*;
  6. }
  7.  
  8. ERROR_print() {
  9. echo "[error] $*"
  10. }
  11.  
  12. DEBUG_print() {
  13. DEBUG echo "[debug] $*"
  14. }
  15.  
  16. DIE() {
  17. DEBUG_print "DIE ($*)"
  18. ERROR_print $*
  19. exit 1
  20. }
  21.  

El otro, un pequeño comando en PERL para obtener los permisos octales de un determinado archivo. Usaría la salida de este comando para armar los objetos 'index' y 'tree':
Código
  1. #!/usr/bin/perl
  2. # Created by Rodriguez Dario A. on Thu Nov 10 07:57:12 AST 2011
  3.  
  4. # not using -w in shabang due to warnings about things we don't care
  5. # unless we are really debugging, such as Fcntl.pm mistakes
  6.  
  7. use strict;
  8. use File::stat;
  9. use Fcntl ':mode';
  10.  
  11. my $stat_mode;
  12. my $octal_perm;
  13. my $user_rwx;
  14. my $group_read;
  15. my $other_execute;
  16.  
  17. unless (@ARGV) {
  18. print "Usage: ls.pl <file 1> ... <file n>\n";
  19. exit 1;
  20. };
  21.  
  22. foreach (@ARGV) {
  23. die "file $_ doesnt exist" unless -f $_;
  24. };
  25.  
  26. foreach (@ARGV) {
  27. $stat_mode=stat($_)->mode or die "cannot stat file $_";
  28. $octal_perm=S_IMODE($stat_mode);
  29. printf "%04o\t%s\n", $octal_perm, $_;
  30. };
  31.  
  32. exit 0;


Y finalmente, el script que agrega archivos al index para el proximo commit, para que vean que conociendo el modelo, algunas operaciónes son realmente simples (sujeto a cambios, pero no se va a complicar mucho):
Código
  1. #!/bin/bash
  2.  
  3. . safa-shelllib
  4.  
  5. if test $# -lt 1; then
  6. echo "incorrect usage"
  7. echo "usage: safa-addfiles <file 1> ... <file n>"
  8. else
  9. for myFile in $@; do
  10. if test -f "$myFile"; then
  11. # verify if the file changed from the last tree
  12. DEBUG_print "safa-diff-from-tree --quiet HEAD \"$myFile\""
  13. safa-diff-from-tree --quiet --perm -- HEAD "$myFile"
  14. if test $? -ne 0; then
  15. echo " o $myFile"
  16. DEBUG_print "nothing changed"
  17. else
  18. echo " + $myFile"
  19. echo "$myFile" >> .safa/addindex
  20. fi
  21. fi
  22. done
  23. fi
  24.  


Obvio que, por dar un ejemplo, safa-diff-from-tree es un script algo más complejo. Espero que se copen.


Saludos
En línea

OpenBSDFreeBSD
Páginas: [1] Ir Arriba Respuesta Imprimir 

Ir a:  

Mensajes similares
Asunto Iniciado por Respuestas Vistas Último mensaje
Controlador de audio. No detecta controlador, no reconoce los drivers...
Multimedia
Firos 1 4,572 Último mensaje 31 Julio 2006, 12:39 pm
por Songoku
Nuevo proyecto
Programación General
SLUGER 0 1,138 Último mensaje 29 Agosto 2011, 04:37 am
por SLUGER
PC Decrapifier 2.2.7: Elimina de tu ordenador nuevo versiones triales y ....
Noticias
wolfbcn 0 1,440 Último mensaje 22 Septiembre 2011, 23:09 pm
por wolfbcn
Controlador de versiones online
Programación General
GeorgArming 9 2,510 Último mensaje 6 Diciembre 2011, 06:27 am
por [Case]
Java MVC ayuda PROYECTO (controlador)
Java
timont29 2 955 Último mensaje 20 Noviembre 2018, 19:57 pm
por timont29
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines