Control de versiones continuo

Question

No he visto un sistema de control de versiones continuo, uno que guarde los cambios en su código a medida que los desarrolla, en lugar de esperar una verificación oficial.Los cambios se guardarán como "no registrados", por supuesto, pero se guardarán para realizar una copia de seguridad y otros podrán verlos antes de que usted realice el registro oficial.

No he visto esto y me pregunto si existe o algo parecido y las razones por las que podría ser o no una buena idea.

En este momento los programadores piensan que el control del código fuente es la integración de paquetes de código, pero ¿por qué no hacer esos paquetes más pequeños e integrarlos continuamente?

-Adán

Answer 1

En este momento, los programadores piensan en el control del código fuente como integración de paquetes de código, pero ¿por qué no hacer que esos paquetes sean más pequeños e integrados continuamente?

Diría que los DVC ya están básicamente haciendo esto ahora, no porque estén descentralizados, sino porque cometer es mucho más rápido ... con Git me comprometo con mucha más frecuencia que con SVN ... también hace que sea simple cometer "trozos" o específico de código (usando git add -i o git gui), y generalmente se centra mucho más en el seguimiento de las líneas de código, en lugar de los archivos completos (como subversión como VCS "tradicional") como la subversión)

Además, la forma en que git funciona inherentemente significa, como usted dijo, "los cambios se guardarían como 'no se registran' por supuesto" ... Cuando se compromete, los cambios son locales, luego los empuja a la máquina remota con una separada Comando ... podría comprometerse cada vez que guarde, luego rebaselos en una sola confirmación si lo desea.

En cuanto a una herramienta que hace "control de versiones continuas", podría hacerlo simplemente con un script de shell, algo así ...

while [ 1 ]; do
   git add -a && git commit -m "Autocommit at $(date)";
   sleep 10;
done

Hay un guión, Cacm (github), que hace algo similar

CACM] observa un directorio específico y comete todos los cambios en un repositorio de Git independiente.

Para usar solo hacer:

cacm --repo dir_of_git_repo --watch dir_to_watch

No estoy seguro de por qué querrías hacerlo ... Encuentro una de las cosas más útiles de usar un VCS es la diferencia de lo que he cambiado (desde la última confirmación). Parece que tener compromisos constantes/automatizados sería solo ruido.

También el "E" Editor de texto Tiene una característica interesante, visualiza la historia de deshacer, con ramificación. Hay un Post de blog en él con capturas de pantalla.

Answer 2

El trabajo del ahorro de autos de constante no es una tarea para un sistema de versión, sino para el editor. Cuando ve una nueva versión en el sistema de versiones, debe representar un cambio significativo de las otras versiones, no todas las palabras con muelles.

Answer 3

Eclipse tiene una característica llamada 'Historia local' que hace exactamente eso. Mantendrá una copia de sus archivos de origen entre guardados. Incluso realiza un seguimiento de las carpetas eliminadas para usted. Me guardó mi trasero varias veces. Puede ver el historial local como control de versiones de bajo nivel que solo ocurre en su máquina local. La desventaja de esto es, por supuesto, cuando trabajas en una máquina diferente, tendrás una historia local diferente.

Answer 4

Puede usar un sistema de control de versiones de distribución, como bazar, git, Mercurial. Entonces puedes comprometerte localmente.

Answer 5

He visto algunos complementos basados ​​en inotify para varios DVCS, sin embargo, esos solo pueden ser muy inteligentes.Realmente, lo ideal es almacenar el repositorio en un sistema de archivos de copia en escritura, de modo que estas frecuentes versiones granulares (e inmutables) de los archivos se mantengan fuera del DVCS.

Como han dicho otros, prefiero hacer muchos pequeños compromisos.Con un DVCS, no tiene que preocuparse por romper el tronco o la rama maestra, presione solo cuando haya terminado.No te preocupes por las revisiones tóxicas mientras editas archivos.

En Linux, uso ext3vaca para almacenar mis repositorios HG/Git.Esto me da el tipo de funcionalidad que usted describe.Es triste decirlo, no conozco nada parecido que sea portátil más allá de Linux.Quizás a algún equipo loco se le ocurra uno en Python.

Esta pregunta ha surgido varias veces antes (aunque cada una en un contexto diferente), por lo que seguramente la necesidad de algo como ext3cow (pero portátil) es obvia.Sin embargo, no quisiera esa hinchazón en un DVCS, especialmente en árboles enormes.

Creo que realmente necesitas solicitar esto al sistema de archivos, no al DVCS.

Answer 6

No quieres registrarte cada cambio. Desea verificar conjuntos atómicos de cambios que pueden funcionar juntos. No desea agregar un parámetro a un método y guardar, haciendo que se registre (y una ejecución de compilación de CI), luego tenga el descanso de compilación porque aún no ha actualizado las llamadas al método.

Answer 7

Te refieres a algo como Subversión Autorsioning?

Descargo de responsabilidad: no digo que la autoversión sea una buena idea para el desarrollo, o que personalmente lo haría, pero la tecnología existe.

Answer 8

Podrías cometer cada línea o personaje con un DVCS como GIT si quieres. En general, creo que es una gran idea comprometerse con la mayor frecuencia posible, al usar un DVCS, para facilitar la búsqueda de problemas con herramientas como Git Bisect. Si quisiera el efecto que describe, podría escribir su editor de elección para comprometerse en cada salvamento ... en la práctica, aunque creo que sería un poco demasiado.

Answer 9

Algunas personas configurarían una rama de desarrollo para este propósito y harían que los desarrolladores cometan sus cambios mientras trabajan antes de fusionarla en una rama de nivel de garantía de calidad. Incluso podría tener un desarrollador que realice cambios importantes en su propia rama antes de cometer y fusionar esos cambios en la rama de desarrollo principal. Entonces, la ramificación puede abordar esto.

Answer 10

Creo que Eclipse lo hace, o solía hacer algo como esto en cada salvación. Me ha guardado varias veces cuando mi código terminó siendo pirateado mientras intentaba identificar un error.

Answer 11

Aquí hay un enfoque diferente. Casi todos los días me encuentro en situaciones en las que algo deja de funcionar y no sé por qué. Rebobelo un par de minutos y verifique qué cambios se han realizado y a qué archivos. Así que estoy de acuerdo en la necesidad de ContRanouos Version Control.

Al mismo tiempo, es cierto que no desea registrar miles de pequeños cambios todos los días en su repositorio.

Ok, entonces esto es lo que haces. Usas ambos pero no los mezcle. Su control de origen debe ser utilizado por todo el equipo y se registra en eso de vez en cuando. Al mismo tiempo, ejecuta algún software local de versión de archivo personal que guarde cada pequeño cambio y le facilita usar la información.

Eso es todo. yo suelo Explorador de historia Desde que ayudé a desarrollarlo, pero también hay otros por ahí.

Answer 12

Es posible que esté interesado en el sistema de control de versiones continuas desarrollado por JetBrains. Todavía no es público, pero muestro algunas características en mi nota clave en JetBrainsday en Malmo: http://new.livestream.com/jetbrains/jetbrainsday1/videos/29348962

Answer 13

Como Dan mencionado, el IBM Visual Age IDE mantuvo cada versión que guardó de un archivo de código fuente. Sin embargo, este enfoque no se limita a IDES; la DEC VMS El sistema operativo adoptó un enfoque similar con su sistema de archivos versionado. En las máquinas virtuales, el nombre completo de cada archivo incluía un número de versión, y cada vez que guardaba un archivo, se creó una nueva copia con una versión número uno más alta que el número más alto anteriormente.

Ninguno de los dos enfoques coincide con el control de versiones como lo conocemos hoy, ya que ambos carecen de ramificación (o, para el caso, cualquier característica diseñada especialmente para facilitar a varias personas que trabajan en el mismo archivo fuente). Pero, ambos tienen el propósito de hacer una copia de seguridad contra el error humano, que para mí es el aspecto más útil del control de versiones.

Answer 14

Teniendo más de unos pocos años de experiencia en programación en Java, todavía recuerdo (con nostalgia) un enfoque novedoso que la edad visual trajo al proceso de desarrollo. La edad visual tenía un enfoque sin archivo al código fuente. El código se almacenó en la base de datos relacional. En general, trabajaría en una vista que muestra un solo método. También tenía una vista de archivo completa, pero no la usaría tanto.

Con respecto al control de versiones, generaría una versión con cada guardado. Puede verificar explícitamente un punto de control, un método, clase/interfaz, paquete o proyecto completo con un número/nombre de versión. También permitió un control de grano más fino de su fuente en el nivel de método. Una vez que comencé a trabajar con Eclipse, mientras heredó muchas características de Visual Age, y hoy tiene una característica de historial que guarda localmente todos los "guardados" de su código, no pude evitar sentir que dio un paso atrás.

Answer 15

Racional Funda tiene el concepto de un vista dinámica. En Windows, su vista de desarrollo se muestra como una unidad mapeada, pero sus cambios en el código se almacenan del lado del servidor tan pronto como presione Guardar. ¿Es esto lo que estás buscando?

Hay, como era de esperar, a comerciar con el trabajo de esta manera, así que como SiRespuesta arriba, esta no es una recomendación ...

Answer 16

¿Qué tal Vesta?

http://www.vestasys.org/