Versionado simple para documentos de texto sin formato (Linux)

Sí, debe usar git*.

Ahora déjame explicarte por qué. Dado el conjunto actual (bastante nebuloso) de criterios en su pregunta, la respuesta parece bastante obvia. Si supieras algo más, ni siquiera estarías haciendo esta pregunta. Ya te has llevado al borde del acantilado, ahora solo necesitas que te convenzan para dar el salto.

_{* O Fossil, Mercurial, Darcs, Bazaar u otro DVCS, según la herramienta frontal que prefiera, que se explicará.}

El panorama actual y algo de historia:

Básicamente, existen tres tipos de sistemas de control de versiones: distribuidos , manipulados y extraídos . Permítame expandirme en esa terminología técnica y cómo cada uno surgió y se aplicaría a su situación.

• puño de jamón

  Entradas destacadas*: CVS, Subversion.

  Antes de que los sistemas DVCS conquistaran el mundo, existían los sistemas VCS. Estos podrían caracterizarse por un repositorio/servidor central y un patrón en estrella de espacios de trabajo/clientes de usuario. Estas fueron una herramienta indispensablemente valiosa para mantener a un equipo de programadores en la misma página e incluso se adaptaron a otros usos. Un solo programador podría trabajar desde múltiples sistemas y jugar con ramas y etiquetas. Salvaron muchos al día. Pero eran inherentemente torpes. Hacen que algunas tareas simples sean más difíciles . Primero estaba la sobrecarga de configurarlos, la necesidad de un servidor y protocolos específicos para conectarlos. Luego estaba el dolor de lidiar con esas veces que hiciste algo mal. Baste decir que estos harían el trabajo para su caso de uso, pero introducirían compensaciones que harían la vida más complicada.

• agotado

  Entrada destacada: RCS.

  Porque cuando un sistema "completamente desarrollado" que involucraba servidores y clientes y autenticación y todo ese jazz era demasiado difícil de digerir, era posible usar un sistema reducido que vivía en su propia pequeña burbuja. RCS hizo esto evitando la idea de un repositorio y simplemente versionando un archivo a la vez. Tenías file.txty sentado justo al lado un file.txt,vque tenía el historial de versiones. Puede crear una instancia fácilmente por archivo y usar un puñado de herramientas simples para trabajar con diferencias, revertir el tiempo, etc.

  Ahora, antes de que digas: "¡Ajá, eso es justo lo que estaba buscando!", sigue leyendo porque ya no es la forma más fácil ni recomendada de hacerlo. La entrada fácil tuvo el costo de un techo operativo bajo que está prácticamente garantizado que obstaculizará su estilo tarde o temprano.

• repartido

  En algún momento, un grupo de programadores inteligentes decidieron que ya habían tenido suficiente dolor y dijeron: "Vamos a comer pastel y también". Sorprendentemente, tuvieron éxito y nacieron los sistemas de control de versiones distribuidas. Estos sistemas combinan lo mejor de ambos mundos: el historial completo de versiones ubicado en su sistema local justo al lado de los archivos originales más la capacidad de compartir su historial e interactuar con el de otros repositorios remotos. Resulta que no hay desventajas técnicas serias para hacer esto.

  La barrera más significativa para algunas tiendas resultó ser la flexibilidad. Debido a que los sistemas no imponen restricciones arbitrarias en la forma en que trabaja, a veces es doloroso migrar de un sistema que lo obliga a tener un determinado flujo de trabajo. De repente tienes que pensar un poco en cómo quieres que funcione tu sistema. Muchas cosas que solían ser necesarias (el nodo central que siempre tiene las últimas novedades de todos) se convirtieron en una convención de asuntos para usar solo cuando se desea, pero hay que sentarse y decir: "Así es como vamos a usar esta herramienta".

Entonces, sentémonos y digamos cómo usaría esta herramienta.

A los efectos de esta respuesta, me ceñiré a git porque es uno de los sistemas más adoptados. Es fácil de instalar en la mayoría de los sistemas (en caso de que aún no esté instalado) y hay una amplia gama de documentación disponible que cubre casi cualquier caso de uso. También es extensible y reconocido por muchos sistemas de terceros, etc. Dicho esto, no es necesariamente mejor que su competencia más cercana, Bazaar o Mercurial.

• Si vive en un ecosistema Ubuntu, es posible que desee echar un vistazo a Bazaar porque Canonical lo usa para todo y se integrará bien con su entorno. Su servicio de plataforma de lanzamiento es similar a Github, pero adaptado al desarrollo de software de Ubuntu. Si planea jugar en ese ecosistema, considere aprender bzren lugar de git para que una herramienta funcione tanto para su mundo personal como para el ecosistema en el que participa. Si no trabaja en proyectos coordinados en la plataforma de lanzamiento, le sugiero que use git.

• Si a alguno de sus colegas le gusta mucho Mercurial, es posible que desee considerar su uso. Es un DVCS muy capaz con algunas ventajas sobre Git. Con frecuencia se alega que es más rápido para algunas operaciones debido a un flujo de datos más optimizado. Todas las herramientas están envueltas en un solo binario en lugar de estar unidas por un montón de herramientas separadas (y a veces redundantes) como lo es Git. Es extensible usando enlaces de Python y es posible crear sistemas externos que se integren muy estrechamente con él. El paradigma es lo suficientemente similar a Git que, una vez que lo aprenda, también podrá cometer errores en un repositorio de Git. Al final, sin embargo, git es el jugador más popular en el campo en este momento y mantenerlo le dará un acceso más rápido para obtener ayuda cuando la necesite.

_{* Mis disculpas a todos los sistemas VCS no nombrados. CVSNT, CA, CC, Perforce, Plastic, PVCS, Star, SVK, Vault, Vesta, VSS y una letanía de otros. Tus nombres nunca serán olvidados ya son solo un recuerdo.}

Cómo gitse adapta a su caso de uso:

Mencionaste haber usado Github un poco. Eso es genial, pero debes tener en cuenta que Github no es git . Es una percepción errónea común que lo que están ofreciendo es una forma gratuita de ingresar al sistema al alojar sus repositorios por usted. En realidad, lo que ofrecen es una capa construida sobre git que es en parte una red social y en parte una gestión de proyectos. Esta es una gran cosa para la comunidad de código abierto. En lugar de tratar de ser un sistema alternativo y luchar contra el mercado, han aprovechado de manera brillante una buena herramienta y han forjado un mercado que brinda un servicio de valor agregado para las corporaciones y sirve a la comunidad al mismo tiempo. Pero Github no es git.

Git puede, de hecho, usarse de una manera mucho más simple.

Similar a RCS, git almacena la información de la versión localmente junto a su contenido. La diferencia notable desde el principio es que lo hace por directorio en lugar de por archivo.

• RCS:

    file1.txt
    file1.txt,v
    file2.txt
    file2.txt,v
  

  El ,varchivo de cada archivo mantiene una lista actualizada del historial del archivo, almacenando el delta entre cada versión consecutiva.

• git:

     directory
     + file1.txt
     + file2.txt
     + .git
       + glob1
       + glob2
  

  Las cosas en la carpeta .git en realidad tienen nombres extraños y son un poco complicadas, pero no es necesario que lo sepas. Conceptualmente, todo lo que hace es almacenar las diferencias entre las versiones de las cosas en su directorio. Básicamente, cada globo es una imagen de cómo se veía su directorio en el momento de cada confirmación. Una gran cantidad de matemáticas sofisticadas mantienen la sobrecarga baja para que solo se guarden los datos delta.

Ahora, esto puede sonar complejo, pero realmente no necesitas saber nada de eso. El conjunto de herramientas realiza un seguimiento de todas las cosas elegantes para usted. El uso básico es tan fácil como RCS, pero le da espacio para crecer en el futuro.

Comenzar sería algo como esto:

# Change to the directory that has files you want to version.
cd ~/pathto/yourtextfiles

# Initialize git to keep track of that folder
git init

Hecho. No se necesitan servidores. Solo usted y su versión controlan los archivos. Excepto que aún no tienes ningún archivo bajo vigilancia, por lo que git no está viendo nada. Git no es codicioso en el sentido de que no realiza un seguimiento de todo en una carpeta, solo las cosas específicas que le indicas. Entonces, el siguiente paso es decirle qué archivos desea rastrear.

# Add some files to the system, assuming these already exist the your dir
git add file1.txt file2.txt

# Commit the changes you just made
git commit -m "initial add"

Tenga en cuenta que, a diferencia de la mayoría de los sistemas, este es un proceso de dos pasos. Antes de enviar cosas y guardarlas en el repositorio como una nueva versión, debe "prepararlas". No todos los cambios que realiza en su directorio de trabajo se asumen automáticamente como algo que desea guardar con cada confirmación. Tal vez cambiaste dos archivos pero solo quieres marcar uno.

# Edit a bunch of files
vim file1.txt
vim file2.txt
vim file3.txt

# Only mark one of them as going it your next commit
git add file2.txt

# Commit it to history
git commit -m "fixed typo"

Tenga en cuenta que los cambios en file1.txt aún no se guardan en el repositorio y file3.txt aún no se rastrea en absoluto. Puede ver que un archivo previamente rastreado tiene cambios no preparados ejecutando git statusy cuáles son esos cambios ejecutando git diff. Si este estado de punto le indicaría que ha realizado cambios en file1.txt y que hay un file3.txt sin seguimiento en su directorio. Diff le mostraría los cambios que realizó en file1.txt desde la última vez que lo preparó y lo confirmó.

Un 'te pillo' que deberías tener advertido acerca de comenzar para que no te moleste en el futuro es que, porque el concepto de git de un repositorio es un directorio completo y los cambios en los archivos se ven como una imagen de ese directorio en un punto en el tiempo: debe considerar tener repositorios separados para proyectos dispares. En lugar de crear un repositorio único a partir de "Mis documentos", debe crear repositorios separados a partir de directorios que contengan algún subconjunto significativo de sus documentos, ya sea por tema, por formato, por proyecto o lo que sea. Esto hará que sea más fácil en el futuro cuando desee trabajar con "todos los documentos relacionados con x" de otra máquina sin tener que tener todos los documentos que haya creado en esa máquina. Git no permitesi desea verificar un subárbol de un repositorio*, es todo o nada, así que erre por el lado de crear muchos repositorios granulares para conjuntos de datos estrechamente relacionados, uno por directorio.

Realmente eso es todo lo que hay para el uso básico. A partir de ahí, casi cualquier cosa que pueda imaginar hacer es posible, pero en ese punto estaría haciendo una pregunta de uso, no una pregunta de recomendación de software.

_{* Subversion, por ejemplo, permitió esto y me acostumbré. Esto me molestó desde el principio cuando asumí que git permitiría algo similar. Tenía TODOS mis archivos personales en un gran repositorio svn e ingenuamente asumí que git sería un reemplazo para eso. Lección aprendida, y mis archivos están mejor porque están categorizados.}

¡Pero las indicaciones de comando dan miedo!

Hay, por supuesto, una multitud de interfaces gráficas de usuario disponibles para mantenerlo alejado de la línea de comandos y representar visualmente lo que sucede con sus archivos. Muchos de estos tienen un sabor similar a IDE y pueden servir como su punto de entrada a la gestión de documentos, utilizándolos para iniciar su editor favorito* o incluso utilizar uno integrado. Dado que preguntó sobre el back-end sobre cómo se deben almacenar sus archivos, le he hecho una recomendación para usar gitcomo administrador de versiones, pero si tiene en mente cómo debería verse y funcionar desde una perspectiva de front-end, debe preguntar eso como una pregunta aparte.

_{* Por supuesto gvim, sería muy adecuado para este caso de uso ;-)}

En conclusión:

¡Entra, el agua esta bien!

¡Una! ¡Dos! ¡Tres! salta git init _

Mira que no fue tan difícil.

Aconsejaría en este caso usar https://draftin.com/ , consulte aquí para obtener un vistazo rápido a las funcionalidades específicas que puede desear usar.

Una desventaja de este software que quiero señalar antes de dar una respuesta detallada a su pregunta es que está diseñado para usarse en línea. Es posible usar el borrador sin conexión a Internet (ver aquí ), pero aún necesita pulirse: la sincronización, que es una función esencial en el borrador, aún debe activarse a mano antes de desconectarse.

1. Control de versiones: SÍ , definitivamente. Es una función central en el borrador, y es genial porque no se interpone cuando no quieres verlo, pero está ahí para servirte cada vez que tú, o cualquier persona con la que compartas tus escritos, se ensucie. arriba con el documento. (De forma predeterminada, las ediciones de otros no se incluyen en sus versiones del documento, debe aceptarlas antes).

2. Compatible con Ubuntu/Mint: SÍ , es un sitio web después de todo. Cualquier navegador decente hará el truco, he probado la función fuera de línea solo en cromo, que tiene un PPA para Ubuntu.

3. Fácil etiquetado/comentario/etiquetado: NO . El punto es que el borrador debe manejar esto por usted, al permitirle marcar versiones principales y secundarias de sus documentos, y dejar en claro quién hizo las ediciones. En este punto, el borrador no sería la mejor herramienta para ti.

4. Navegación simple de etiquetas/etiquetas, búsqueda: no estoy seguro . Bueno, si el borrador de etiquetas se ajusta a tus necesidades, al menos.

5. Simple "recuperación" de versiones anteriores: SI . No solo puede recuperar versiones anteriores, sino que también puede mantener los bits útiles en ambas versiones y editar la versión actual mientras ve la diferencia con cualquier otra versión.

6. posibilidad de hacer diffs: SI . La cosa a veces se equivoca (el caso más molesto sería al reescribir un párrafo: draftin cree que reemplazo cada oración por una nueva, mezclando lo antiguo y lo nuevo en la diferencia, cuando preferiría que el nuevo párrafo estuviera separado del anterior). viejo, pero los códigos de color hacen que sea menos horrible de manejar). Sin embargo, las diferencias funcionan bien.

7. posibilidad de sincronizar con diferentes máquinas: SI , por la naturaleza de página web de la cosa. Sin embargo, el modo fuera de línea es extraño y requiere sincronización manual.

8. estructura/jerarquía de directorio simple para documentos: SÍ, pero , incluso un poco demasiado simple. Puede poner documentos en una carpeta, pero todavía tengo que encontrar una manera de anidar carpetas, lo cual es un gran inconveniente.

En resumen, el borrador se impone a los usuarios, lo cual es genial si te gusta (a mí me encanta). Seguro que merece una oportunidad en su caso, pero su muy baja flexibilidad (sin embargo, proporciona una API, si le gusta la codificación) podría limitar su alcance.

Usa " fósil "

El excelente trabajo de supererogación de @Caleb (arriba) todavía tiene sentido y una lectura convincente, años después de haberlo publicado.

Sin embargo, después de haber trabajado durante siete años para conseguir un sistema que me encanta, lo he encontrado en Fossil . Ha aparecido una o dos veces en SoftwareRecs, pero tiende a pasar desapercibido (OMI).

Para este usuario, Fossil responde a todos los beneficios que Caleb documentó con respecto a un sistema basado en Git, y agrega un par de beneficios para mis "hábitos" cerebrales/de trabajo . Y responde maravillosamente a mi caso de uso/criterio original (por supuesto):

• control de versiones (¡esencial, obviamente!)
• Compatible con Ubuntu/Mint (PPA sería genial) | ¡pero no se necesita PPA!
• fácil etiquetado/comentario/etiquetado de "confirmaciones"
• exploración simple de etiquetas/etiquetas
• búsqueda simple de etiquetas/etiquetas
• simple "recuperación" de versiones anteriores
• posibilidad de hacer diffs
• posibilidad de sincronizar con diferentes máquinas
• estructura/jerarquía de directorios simple para documentos

Beneficios adicionales

Básicamente, hay dos beneficios para mí (nb, los usuarios experimentados de Git no quedarán impresionados con estos):

1. Fossil es fácilmente autohospedado . Esto también podría ser cierto para Git , pero me parece que Fossil puede ser más autohospedado que Git. <shrug/>Aunque este no es uno de mis criterios esenciales de mi publicación original, he llegado a favorecer este enfoque (es decir, no depender de servicios de terceros).
2. Si bien los procesos son muy similares a los de Git , el enfoque de Fossil (nuevamente) me parece un poco más simplificado (o simple), por lo que parte de la angustia que he experimentado al usar Git a lo largo de los años (como lo he hecho) es un sin problema
3. ¡Prima! También es muy simple de usar en todas las plataformas (regularmente me muevo entre Ubuntu y MacOS); una vez más, Git, por supuesto, también se puede usar en cualquier plataforma, pero la barra de entrada parece un poco más alta en los sistemas que no son Linux para Git que para Fossil.
4. ¡Bono 2! Fossil ha sido descrito como "GitHub-in-a-box", ya que su único archivo ejecutable (fácil de instalar en sistemas Win/MacOS/*nix) incluye no solo control de versiones, sino también seguimiento de problemas, wiki, foro, un "chat "como instalación y una interfaz web integrada... todo en uno. ¡Jubiloso! (No es que uno necesite usar esas funciones adicionales, pero están ahí sin costo adicional, por así decirlo).

El comentario irónico de Caleb (¡sin duda!) sobre Fossil (entre otros) ("Sus nombres nunca serán olvidados ya son solo un recuerdo") es poco probable que sea el caso de Fossil ... es lo que gestiona el desarrollo de SQLite , ¡así que no va a desaparecer pronto!:)

git es una buena solución para el control de versiones. Especial para texto plano.

• Investigue el soporte del sistema de control de versiones integrado en ReText. (No puedo encontrar)
• Prueba las interfaces de git. Me gusta la git-cola.
• Pruebe las herramientas externas de diferenciación/combinación. Me gusta Meld.