Herramientas de colaboración para dummies / profesores.

Suponga que los coautores de dos o más instituciones diferentes están escribiendo un artículo en látex, y les gustaría hacerlo mejor que enviar borradores repetidamente por correo electrónico.

Se dan cuenta de que pueden abrir de forma gratuita una cuenta de Dropbox, compartir la contraseña y sincronizar la versión del documento en su computadora con la de Dropbox. Sin embargo, si dos personas están editando simultáneamente la misma sección, se sobrescribirán mutuamente los cambios.

También han escuchado que los sistemas de control de versiones como SVN y Git tienen herramientas para fusionar cambios concurrentes, que funcionan razonablemente bien. Sin embargo, la documentación de estos productos es bastante difícil de leer, y se centra más en cómo deshacer los cambios y en cómo manejar diferentes "ramas" en lugar de en las necesidades básicas de los coautores que escriben un documento.

¿Existe una exposición simple paso a paso sobre cómo usar un sistema de control de versiones en esta configuración:

• repositorio central
• copias locales
• fusión "inteligente"
• sin ramas

?

De los sistemas de control de versiones estándar, ¿cuál es el más fácil de usar? (Estamos hablando de profesores teóricos de informática aquí).

¿Hay herramientas aún más simples que solo se sincronizan con la fusión inteligente, sin control de versiones?

Por el contrario, ¿las personas que usan sistemas de control de versiones para incluso escribir un documento de autor único realmente sienten que la capacidad de deshacer ilimitada vale la complejidad adicional?

En primer lugar: si está interesado en la edición colaborativa en tiempo real, pruebe algo como el gobby . Te permite literalmente editar un documento al mismo tiempo.

En cuanto a los sistemas de revisión, solo estoy familiarizado con SVN. Esto es lo que haces, después de instalar Subversion, por supuesto:

1. Haz que alguien te configure un repositorio y te dé URL, nombre de usuario y contraseña
2. Ve a donde quieres tener tu copia local
3. En un shell (línea de comando?), Escriba: svn co url://to.your/repository(check-out). Ahora aparece una nueva carpeta con el contenido del repositorio.

Eso es todo. Ahora los comandos más básicos:

• Cada vez que agregue un nuevo archivo foo, ingrese:svn add foo
• Cada vez que desee eliminar un archivo, ingrese: svn rm foo
• Cada vez que haya realizado cambios, ingrese: svn ci(check-in)
• Siempre que desee obtener las cosas más nuevas, ingrese: svn up(actualización)

También hay comandos para mover, copiar, bifurcar, resolver conflictos, ... pero siempre que no intentes cosas divertidas, estás de acuerdo con lo anterior. Si algo se rompe o parece, haga una copia de seguridad de sus ediciones, elimine toda la carpeta y revise todo nuevamente. Eso es para svn como reiniciar para Windows.

Anexo: Veo que parece estar preocupado por las "fusiones inteligentes". Supongo que se refiere a tener que fusionar diferentes versiones de un archivo, con el supuesto de que dos personas agregaron cosas en partes disjuntas del documento. Hasta donde yo sé, svn trataría eso como un conflicto, y probablemente con razón. No creo que haya un procedimiento general que garantice que obtenga lo que desea después de que dos personas manipulan la misma fuente. Hay clientes gráficos svn que visualizan tales conflictos y lo ayudan a resolverlos; son prácticamente espectadores diferentes donde puedes elegir qué versión mantener para cada línea conflictiva). Sin embargo, requerirá trabajo.

Noto que nadie está dando el tutorial "pequeño" para GIT , así que intentaré cubrirlo. GIT es más rápido y superior a SVN, pero quizás sea más fácil para usted obtener una cuenta SVN en un servidor de su universidad, ya que SVN está bien establecido. También muchos de sus colaboradores sabrían cómo usarlo.

Incluso si colabora usando SVN, es posible que desee usar GIT para sus propias versiones locales (¡lo hago!).

Primer bit de advertencia : GIT es muy poderoso y para el uso básico es solo un poco más difícil de usar que SVN (por ejemplo, una opción para agregar en la línea de comando; dos pasos se comprometen para el repositorio central).

$\Delta$

Comandos básicos asumiendo que ya tienes un repositorio

• Clonar un repositorio: git clone <url>
• Actualice su repositorio local: git pull <repo>o simplemente git pullsi clonó como se indicó anteriormente.
• El comando pull realmente hace ambas cosas git fetchy git merge. El primero "busca" cosas del servidor central, y el segundo aplica una fusión de sus archivos y los del servidor.

La fusión es automática siempre que no haya ediciones simultáneas en las mismas partes de algunos archivos. Si la fusión falla, su directorio de trabajo permanece en un "estado de fusión", lo que significa que debe solucionar los conflictos y luego debe confirmar la copia fusionada. Si aún tiene conflictos no gestionados en sus archivos, la confirmación volverá a fallar, no se confirmó basura.

• Añadir un nuevo archivo que estar comprometido: git add <file name>.
• Confirme los cambios en su repositorio local : git commit -am "<textmessages>"o git commit -asi desea editar los mensajes de confirmación.
• Empuje los cambios en su repositorio local al repositorio central .

Tenga en cuenta que para enviar cambios a su repositorio central primero tiene que comprometerse con su repositorio local y debe empujar todas las confirmaciones (incluso más de una) a su repositorio central .

Crear un repositorio local de usuario

• Creación de un repositorio git initen cualquier carpeta que desee.
• ¡Hecho!

Cree un repositorio público compartido (también privado si paga en efectivo) con una buena GUI.

• Usa GitHub

Cree tantos repositorios públicos / privados con diferentes grupos de usuarios pero sin GUI.

• Solicite una cuenta SSH sin contraseña en una máquina accesible.
• No se preocupe ya que la autenticación se realiza mediante claves SSH.
• Instale la gitosis de acuerdo con este tutorial .
• ¡Ahora puede administrar su propio servidor git editando un solo archivo y enviándolo al repositorio!

Git no necesita un servidor central : cualquier carpeta en su computadora puede usarse como repositorio, para que pueda jugar con git y hacer que sus pruebas estén fuera de línea. Puede inicializar un repositorio y simular tres colaboradores en otras tres carpetas sin enviar un bit en la red. Esto se debe a que cualquier copia clonada del repositorio es un repositorio con todas las funciones en el que puede comprometerse. Esto es bueno si desea trabajar en un vuelo entre Estados Unidos, China o Europa.

Documentos de Google ( https://docs.google.com ) proporciona excelentes herramientas para crear documentos juntos (incluida la edición en tiempo real). Almacena todo en línea para usted y se integra bien con su cuenta de Gmail. De forma predeterminada, Google Docs no tiene compatibilidad con LaTeX, pero puede habilitarla yendo aquí:

http://docs.latexlab.org/

No estoy seguro de qué tan bien funciona para la reversión, pero estoy seguro de que hay una característica para ello. He oído hablar de algunas personas que usan el complemento LaTeX de Google Wave para elaborar bocetos preliminares de documentos.

Hago que mis coautores aprendan Mercurial, y solía hacerles aprender Subversion. Si eres un fanático de Subversion, solo lee esto , todo es cierto.

Independientemente del sistema que utilice, lo más difícil es lograr que la otra persona instale el software y comience a usarlo. Skype es la solución perfecta. Las versiones recientes de Skype permiten "compartir el escritorio", lo que realmente ayuda cuando desea guiar a su coautor a través del procedimiento de instalación. Y he usado el uso compartido directo del escritorio combinado con Skype para escribir un documento con mi coautor. Funciona bastante bien

Lo que realmente se necesita es un "Github para científicos". Algo que proporciona un repositorio, tiene control de versiones, edición colaborativa, etc. Adivina qué, hay http://www.scribtex.com/ .

Aquí hay un nuevo editor colaborativo de Latex en línea llamado WriteLatex que parece prometedor, como una ventanilla única para muchas necesidades / requisitos de escritura científica.

• funciona en dispositivos móviles
• tiene vista previa en tiempo real
• intercambio fácil / privado
• encuentra errores de látex
• permite agregar bibliotecas / estilos de látex
• almacenamiento en la nube

el coautor John Hammersley publicó un anuncio en tcs se meta aquí y responde a los comentarios (5 votos más en el anuncio y aparecerá en el sitio principal). parece que con el tiempo podría convertirse en una herramienta valiosa para la comunidad tcs y tal vez los autores podrán implementar algunas características populares específicamente a pedido.

¿Qué pasa con los sistemas simples, soluciones:

• Documentos de Google, escritor de Zoho ... y otras herramientas de colaboración.
• Dropbox maneja situaciones en las que dos personas intentan realizar cambios en el mismo archivo. La segunda persona que comete se renombra su archivo (X.txt -> X.txt_blabla ...), y el archivo original (X.txt) se actualiza con la versión más reciente. Más información sobre: Ayuda de Dropbox: "¿Qué sucede si dos personas cambian el mismo archivo?"

Está fuera de discusión, pero a veces hay situaciones en las que parte del grupo es capaz de soluciones simples como SVN, mientras que otra parte del grupo es capaz de controlar la versión distribuida como GIT. En tales situaciones, la cooperación es posible:

• git-svn - Operación bidireccional entre un repositorio de Subversion y git
• Git - Curso intensivo SVN
• Uso efectivo de Git con Subversion

Recientemente descubrí sharelatex.com y lo utilicé con mi colaborador para ser coautor de un artículo. Me gustó tanto que mi plan actual es usarlo para todos mis proyectos. Algunas características notables:

• TeXing en el navegador en tiempo real (como Google Docs, pero hecho para TeX, resaltado de sintaxis y todo).

• Compilación en el navegador y visualización de PDF

• Soporta proyectos con múltiples archivos.

• Tiene una característica de historia

• Se sincroniza con Dropbox (que pronto se lanzará públicamente, desde su estado beta actual). De esta forma, puede descargar el almacenamiento de copias de seguridad, etc. en Dropbox. Dependiendo de cómo se haga, esto también debería permitirle usar sharelatex incluso si sus coautores no lo desean, siempre que estén dispuestos a usar Dropbox para compartir archivos.

• Puede descargar / cargar su proyecto en cualquier momento, para que no se quede atascado con sharelatex si algo sale mal o cambia de opinión o lo que sea.

El único inconveniente (pero creo que vale la pena): aunque usar sharelatex es gratuito, algunas de sus características no lo son. En particular, para usar la sincronización de Dropbox (cuando la publiquen), o si desea que más de 6 coautores trabajen en el mismo proyecto sharelatex, debe pagar $ 8 / mes. o $ 80 / año [a partir de abril de 2013]. Sin embargo, una vez que lanzan la sincronización de Dropbox, me parece un precio muy justo.

[Descargo de responsabilidad: no tengo ninguna relación con sharelatex o sus empleados que no sea que uso su producto.]

SVN es la herramienta desarrollada para este propósito. Me esforzaría por aprenderlo. No es más complicado que aprender a usar, por ejemplo, el paquete Algoritmo m2e Latex o uno de los paquetes Latex creadores de diapositivas pdf.

Dicho esto, uso CVS en lugar de SVN. Hay un mejor soporte de los administradores de CS en nuestra institución (el servidor SVN es más administrado por el usuario). Además, agradezco que los archivos de la versión subyacente sigan ahí y sean editables si algo sale muy mal.

Hay 2 inconvenientes en comparación con SVN. El cambio de nombre de archivo no es tan bueno, pero puedo vivir con eso (elige un buen nombre la primera vez) El segundo problema es que se necesita una cuenta CS local para acceder al repositorio. Por lo tanto, desde otra institución, el acceso solo es posible si primero se crea una cuenta. Por supuesto, no espero que esto sea un problema real en ningún lado; un miembro del departamento local probablemente pueda patrocinar esa cuenta.

La restricción de acceso local se debe al hecho de que los administradores no quieren admitir un pserver. (Más difícil de asegurar, etc.)