Alternativas al control de versiones profesional [cerrado]

Nos estamos asociando con algunos no programadores (escritores) que necesitan contribuir a uno de nuestros proyectos.

Ahora simplemente no les gusta la idea de usar Git (o cualquier otra cosa) para la versión que controla su trabajo. Creo que esto se debe a que simplemente no les parece que valga la pena comprender los conceptos retorcidos del control de versiones. (Cuando les presenté por primera vez la ramificación y la fusión, parecía que los estaba ofendiendo).

Ahora, no estamos en condiciones de educarlos o convencerlos de que lo usen. Solo estamos tratando de encontrar alternativas para tener todo su trabajo versionado (que es lo que necesitamos), y obtienen un flujo de trabajo fácil y se concentran en lo que hacen.

Se me ocurrieron algunas ideas ...

• dígales que guarden su trabajo como un archivo separado cada vez que realicen algún cambio no trivial, y luego use un diff de nuestro lado para rastrear los cambios.
• escribir un programa (en Python) que implemente los "hitos" en CSSEdit de alguna manera.

Sobre el proyecto:

Es un sistema de procesamiento de lenguaje natural (escrito en C + Python). Hemos contratado algunos escritores para preparar entradas para el sistema en diferentes idiomas. Y a medida que evolucionamos el software, necesitaríamos que esos escritores realicen cambios en sus entradas (artículos). Algunas veces los cambios son muy pequeños (una o dos palabras), y otras veces grandes.

La razón por la que necesitamos controlar esos cambios es porque cada cambio pequeño / grande en la entrada tiene el potencial de cambiar drásticamente la salida del sistema.

cuando les presenté por primera vez la ramificación y la fusión, parecía que los estaba ofendiendo

Esto probablemente se deba a que la ramificación y la fusión son conceptos avanzados, e infinitamente menos útiles que simplemente realizar un seguimiento de los cambios.

Entonces, ¿por qué no explicar simplemente "commit" (guardar) y "actualizar"? Dos conceptos realmente simples . Estoy seguro de que puedes explicarlo en menos de 10 minutos.

Si realmente quieres usar ramas separadas y cosas así, puedes hacer esa parte tú mismo sin involucrarlas.

Un enfoque poco ortodoxo sería usar Dropbox . Haga que los autores guarden los archivos en el directorio de Dropbox y obtendrá versiones y copias de seguridad de forma gratuita. Además, básicamente no hay una curva de aprendizaje para los autores.

Para git, parece que al final terminarás proporcionando a los autores las versiones de rama correctas de todos modos, así que solo coloca el repositorio de git en el buzón y maneja la ramificación y la fusión de los autores.

Verdaderamente, la respuesta está en su edición: "Hemos contratado a algunos escritores" - a veces solo tienes que tener una mente sangrienta ... quieren tu dinero, tienen que hacer lo que quieras, siempre que lo que quieres no sea irrazonable.

El argumento que usted hace es el argumento que ya ha avanzado: necesitamos poder hacer X, Y y Z para que el producto funcione, y para hacerlo , necesitamos que lo haga. Seremos tan solidarios como podamos, pero para que esto funcione (y, por lo tanto, para que continúe como una fuente de ingresos para usted, el escritor), esto tiene que suceder.

Tiendo a aceptar que una solución adecuada basada en Wiki parece ser una buena combinación, pero el desafío aquí es cómo encontrar un compromiso entre su flujo de trabajo y sus requisitos.

Repetiré el punto clave: para que su proyecto sea un éxito, necesita que los artículos sean versionados, por lo tanto, aquellos que trabajan en los artículos deben cumplir con un conjunto de reglas acordadas, si esto no sucede , obtendrá quemado y, por extensión, también lo harán los escritores.

He tenido que lidiar con una situación similar como esta antes. Al final, solo designamos a un desarrollador (yo) como el punto de contacto de control de versión para el tercero.

La tercera parte me enviaba por correo electrónico un archivo zip de sus archivos de proyecto todos los días y yo hacía el registro por ellos. Configuré un espacio de trabajo de proyecto separado y una cuenta svn para ellos y descomprimiría los archivos en ese espacio de trabajo sobrescribiendo lo que estaba allí y luego haría el registro bajo esa cuenta.

No era lo más divertido que tenía que hacer todos los días, pero a veces es más importante hacer el trabajo.

Una ventaja más fue que me ayudó a revisar su trabajo para asegurarme de que no estuvieran registrando un código y datos incorrectos que podrían romper la compilación.

SparkleShare es un clon de dropbox basado en git, creo que se adapta a tus necesidades.

SparkleShare crea una carpeta especial en su computadora. Puede agregar carpetas alojadas de forma remota (o "proyectos") a esta carpeta. Estos proyectos se mantendrán sincronizados automáticamente con el host y todos sus pares cuando alguien agregue, elimine o edite un archivo.

... aquí hay algunos ejemplos de lo que hace bien y menos bien con las caras sonrientes:

Excelente

• Cambio frecuente de archivos de proyecto, como texto, documentos de oficina e imágenes
• Seguimiento y sincronización de archivos editados por varias personas
• Revertir un archivo a cualquier punto de su historia
• Evitar espiar sus archivos en el servidor usando encriptación

No muy bien

• Copias de seguridad completas de la computadora
• Almacenar tu colección de fotos o música
• Grandes archivos binarios que cambian a menudo, como proyectos de edición de video ...

Actualización (noviembre de 2015) : el proyecto parece estar abandonado (última versión de abril de 2014).

Si puede proporcionar un espacio de trabajo preparado con un uso transparente de VCS, utilizarán VCS. No enseñe a los no programadores a usar VCS en la forma del programador

Simplemente encuentre el editor con soporte VCS incorporado, configúrelo y muestre pasos fáciles adicionales en sus trabajos.

Solo un ejemplo: Editplus conoce Subversion, tiene la capacidad de realizar operaciones SVN básicas dentro de la ventana del editor. El último Editplus incluso puede usar TortoiseGIT para la integración de Git

Editar : se encontró una solución alternativa: EasySVN , que, configurada correctamente, supervisa la copia de trabajo y realiza la confirmación automática y la automatización, lo que permite utilizar cualquier herramienta de creación para el usuario final y los formatos de cualquier documento

¿Qué pasa con la configuración de un WebDAV ?

Manejará automáticamente el historial de versiones en línea recta para ellos. Todo lo que tienen que hacer es conectarse al servidor como si fuera una unidad de red y cada guardado será una confirmación.

Google Docs

Google Docs puede hacer lo que quieras. File > See Revision Historyle permitirá realizar un seguimiento de los cambios.

También tiene el problema de entregar archivos de un lado a otro de forma gratuita; solo comparte el documento entre todos.

Finalmente, es fácil de usar; los escritores ni siquiera tienen que saber que están sucediendo versiones.

SO Agnóstico

Escriba un programa Python en el que pueda arrastrar y soltar un archivo, ese programa puede hacer el git addy git commity lo que no, y nunca tienen que lidiar con él.

o

Utilice un sistema de archivos basado en WebDav que pueda montar en su máquina y haga que el servidor haga las gitcosas de forma transparente.

OSX / Linux

Escriba un complemento FUSE basado en Python que tome los archivos y los confirme en git. Luego pueden abrir y guardar del sistema de archivos montado de forma transparente. Hay algunos recursos de FUSE para Windows , pero probablemente no valga la pena engañarlos.

Ventanas

Podría escribir un código para usar FileSystem Filter Drivers para hacer las gitcosas de forma transparente .

Ah, las alegrías de los no codificadores bromeando. Sugeriría configurar un entorno git / mercurial para ellos. Dígales que guarden todo en un formato que el repositorio pueda manejar. Con tortoisegit o tortoisehg , no necesitan saber cómo funciona el repositorio. Simplemente verifican si tienen un signo de exclamación en el directorio de su proyecto, hacen clic derecho en el archivo ofensivo y hacen clic en confirmar. Escriba una sinopsis de los cambios (son escritores, ¿verdad?) ¡Y listo!

Un paso adicional en el flujo de trabajo para ellos, pero nada sobre fusionar / ramificar / cosas geniales. El entorno preconstruido ya está configurado para estar en la rama de escritores, por lo que no ven el código. Haga que un script los sincronice automáticamente todos los días. Más tarde, después de que estén acostumbrados a comprometerse, puede mostrarles funciones adicionales. La capacidad de ver qué cambió cuando es tan útil que no podrán prescindir de ella una vez que se cuela en su flujo de trabajo.

¿Qué pasa con Share Point? Sé que no es popular en el mundo del desarrollo, pero si sus escritores usan Windows como sistema operativo, funcionará bien y realmente no sabrán que están usando el control de versiones (una gran ventaja para mi trabajo).

Esta solución también les impide lidiar con cualquier cosa que los asuste demasiado, ya que parece que les dan miedo las cosas nuevas.

¿Podría configurar una herramienta que supervise el sistema de archivos donde los escritores guardan sus archivos y haga que se confirme automáticamente cada vez que guarden?

Si lo coloca en un recurso compartido de red, podría hacer toda la configuración sin involucrarlos en absoluto; pero cada vez que proporcionen una versión actualizada para que su equipo la use, se agregará a git por usted.

¿Viste Plastic SCM? Están tratando de simplificar su uso.

Si solo desea copias de seguridad versionadas, puede usar Dropbox o puede configurar el servicio de copia de seguridad de Windows. O puede instalar Crashplan u otro producto similar.

Para Mercurial DVCS, existe una interfaz de usuario llamada EasyMercurial , cuyo objetivo declarado es proporcionar explícitamente una vista simple de las operaciones básicas de control de versiones.

EasyMercurial está destinado a ser:

• fácil de enseñar y aprender indicativo del estado real del repositorio, usando una representación gráfica de historia
  • reconociblemente cercano al flujo de trabajo normal de la línea de comandos para Mercurial consistente en todas las plataformas

No estamos tratando de producir "el mejor" cliente de Mercurial para ningún propósito. Alentamos activamente a los usuarios a pasar a otros clientes a medida que sus necesidades evolucionan. El objetivo es simplemente proporcionar algo accesible para principiantes en pequeños grupos de proyectos que trabajan con un repositorio remoto compartido.

Recomiendo probarlo.

He tenido que trabajar muchas veces con personas que no son programadores (en su mayoría artistas gráficos, y si sus escritores tienen tan poca idea de cómo administrar los archivos de trabajo como artistas, entonces están en ... h'mmm ... diversión ... .). Hay tres enfoques posibles:

1. Imagina que son programadores, intenta enseñarles cómo usar el control de versiones. Esto no funcionará y tendrás peleas constantes.
2. Escríbales una herramienta muy simple que simplemente tome la versión actual y la pegue en algún lugar para que puedan rebobinar los archivos de ayer si es necesario. Esto es posible, y lo hice para un equipo de creadores de DVD (haciendo menús, gráficos, todo tipo de cosas) hace muchos años con cierto éxito: la herramienta que escribí fue un contenedor de un solo clic para PkZip (puede ver que esto fue hace un tiempo) y simplemente comprimió el directorio de trabajo y nombró el archivo para la fecha + hora.
3. Toma el control de lo que producen tú mismo. Deje en claro que sus archivos tienen que ser entregados a un programador y solo se convierten en parte del proyecto cuando el programador acepta los archivos: el programador los verifica en el control de versiones y el contenido se administra de manera profesional.

Personalmente, creo que la opción 3 es el camino a seguir. Significa algo de dolor e irritación para quien tiene que tomar las entregas de archivos y hacer que se registren, pero mucho menos que cualquier otra opción.

También diría, tenga en cuenta que los no programadores entregarán archivos con cualquier nombre de archivo antiguo que pueda imaginar. Las convenciones de nombres son extrañamente extrañas para ellos. Le darán un archivo llamado "Picture" o algo así y luego, cuando les diga las cosas que están mal, le dará un archivo llamado "Picture_Final", que solo corrige alrededor de 3 de las fallas. Cuando señales esto, obtendrás otro archivo, llamado "Picture_NewFinal", y luego (si tienes suerte) "Picture_NewFinal2", aunque es posible que en este momento desechen cualquier sentido de desarrollo histórico y lo llamen "Icono de llave inglesa cosa".

Una vez más, puede intentar imponer una convención de nomenclatura, lo que significa decirles de antemano cómo se llamará a cada archivo, o puede pasar horas descifrando y renombrando lo que le envían. De todos modos, aquí diría que desea la hoja de cálculo para su propia cordura, así que intente hacer que la sigan: simplemente no se sorprenda cuando no lo hagan.

Espero que ayude, ¡diviértete!

Si existe la posibilidad de que dos de ellos necesiten trabajar en el mismo objetivo a la vez Y si puede ocuparse de todo su trabajo en archivos de texto, probaría los documentos compartidos de Google.

Tiene una increíble capacidad de edición / colaboración múltiple, con mucho, la mejor que he visto. También tienen una versión completa y se pueden exportar como archivos de texto.

Pero esos son dos ifs bastante grandes.

Déjelos trabajar en una carpeta, guardando los archivos como de costumbre.

Una vez al día (o semana, etc.) copie el contenido de esa carpeta a backup_dd_mm_yyyy La mayoría del código fuente de los sistemas ocupa una cantidad trivial de espacio dado el espacio disponible en estos días.

Usted, ellos, un tercero, una herramienta o un script pueden hacer la copia.

Esto limita la pérdida a un día, da un historial, es transparente para ellos.

No es perfecto para ninguna de las partes, sino una respuesta que busca alcanzar un punto medio.