Ferramentas colaborativas para manequins / professores

Suponha que co-autores de duas ou mais instituições diferentes estejam escrevendo um documento em látex e queiram fazer melhor do que enviar repetidamente os rascunhos por e-mail.

Eles percebem que podem abrir gratuitamente uma conta da caixa de depósito, compartilhar a senha e sincronizar a versão do documento em seu computador com a da caixa de depósito. Se duas pessoas estiverem editando simultaneamente a mesma seção, elas substituirão as alterações.

Eles também ouviram dizer que sistemas de controle de versão como SVN e Git têm ferramentas para mesclar mudanças simultâneas, que funcionam razoavelmente bem. A documentação desses produtos, no entanto, é bastante difícil de ler, e é mais focada em como desfazer alterações e em como gerenciar "ramificações" diferentes, e não nas necessidades básicas dos coautores que escrevem um artigo.

Existe uma exposição passo a passo simples sobre como usar um sistema de controle de versão nesta configuração:

• repositório central
• cópias locais
• mesclagem "inteligente"
• sem galhos

?

Dos sistemas de controle de versão padrão, qual é o mais fácil de usar? (Estamos falando de professores teóricos de ciência da computação aqui.)

Existem ferramentas ainda mais simples que sincronizam apenas com a mesclagem inteligente, sem controle de versão?

Por outro lado, as pessoas que usam sistemas de controle de versão para escrever um artigo de autoria realmente sentem que o recurso de desfazer ilimitado vale a pena a complexidade extra?

Primeiro: se você está interessado em edição colaborativa em tempo real, tente algo como gobby . Permite editar literalmente um documento ao mesmo tempo.

Quanto aos sistemas de revisão, estou familiarizado apenas com o SVN. Isto é o que você faz, depois de instalar o subversion, é claro:

1. Peça a alguém para configurar um repositório e fornecer URL, nome de usuário e senha
2. Vá para o local em que deseja obter sua cópia do lokal
3. Em um shell (linha de comando?), Digite: svn co url://to.your/repository(check-out). Agora, uma nova pasta com o conteúdo do repositório é exibida.

Isso é tudo. Agora os comandos mais básicos:

• Sempre que você adicionar um novo arquivo foo, digite:svn add foo
• Sempre que você desejar remover um arquivo, digite: svn rm foo
• Sempre que você tiver feito alterações, digite: svn ci(check-in)
• Sempre que você quiser obter as novidades, digite: svn up(atualizar)

Também existem comandos para mover, copiar, ramificar, resolver conflitos, ... mas desde que você não tente coisas engraçadas, você estará bem com o que foi dito acima. Se alguma coisa quebrar ou parecer fazer backup de suas edições, exclua a pasta inteira e faça o checkout de tudo novamente. Isso é para svn como reiniciar para Windows.

Adendo: Vejo que você parece estar preocupado com "fusões inteligentes". Suponho que você se refere a versões diferentes de um arquivo mesclado, com a suposição de que duas pessoas adicionaram coisas em partes separadas do artigo. Até onde eu sei, o svn trataria isso como um conflito, e provavelmente com razão. Eu não acho que exista um procedimento geral que garanta que você obtenha o que deseja depois que duas pessoas manipularam a mesma fonte. Existem clientes svn gráficos que visualizam esses conflitos e ajudam a resolvê-los; eles são praticamente espectadores diferentes, onde você pode escolher qual versão manter para cada linha conflitante). Isso exigirá trabalho, no entanto.

Percebo que ninguém está dando o tutorial "pequeno" para o GIT , então tentarei cobri-lo. O GIT é mais rápido e superior ao SVN, mas talvez seja mais fácil obter uma conta SVN em um servidor da sua universidade, pois o SVN está bem estabelecido. Talvez alguns de seus colaboradores saibam como usá-lo.

Mesmo que você colabore usando o SVN, convém usar o GIT para seu próprio controle de versão local (eu sim!).

Primeiro aviso : o GIT é muito poderoso e, para uso básico, é apenas um pouco mais difícil do que o SVN (por exemplo, uma opção a ser adicionada na linha de comando; duas etapas são confirmadas para o repositório central).

$\Delta$

Comandos básicos assumindo que você já possui um repositório

• Clone um repositório: git clone <url>
• Atualize seu repositório local: git pull <repo>ou apenas git pullse você clonou como acima.
• O comando pull realmente faz ambos git fetche git merge. O primeiro "busca" coisas do servidor central e o segundo aplicam uma mesclagem de seus arquivos e os do servidor.

A mesclagem é automática, desde que não haja edições simultâneas nas mesmas partes de alguns arquivos. Se a mesclagem falhar, o diretório de trabalho permanecerá em um "estado de mesclagem", o que significa que é necessário corrigir os conflitos e, em seguida, você deve confirmar a cópia mesclada. Se você ainda tiver conflitos não gerenciados em seus arquivos, a confirmação falhará novamente, sem lixo confirmado.

• Adicionar um novo arquivo a ser cometidos: git add <file name>.
• Confirme as alterações no seu repositório local : git commit -am "<textmessages>"ou git commit -ase você deseja editar as mensagens de confirmação.
• Envie as alterações no seu repositório local para o repositório central .

Observe que, para enviar alterações ao seu repositório central, você deve primeiro confirmar o repositório local e enviar todas as confirmações (ainda mais de um) ao repositório central .

Crie um repositório local do usuário

• Criação de um repositório git initem qualquer pasta que você desejar.
• Feito!

Crie um repositório compartilhado público (também privado se você pagar em dinheiro) com uma boa interface gráfica.

• Use o GitHub

Crie como muitos repositórios públicos / privados com diferentes grupos de usuários, mas sem GUI.

• Solicite uma conta SSH sem senha em uma máquina acessível.
• Não se preocupe, pois a autenticação é feita por chaves SSH.
• Instale Gitosis de acordo com este tutorial .
• Agora você pode administrar seu próprio servidor git editando um único arquivo e enviando-o para o repositório!

O Git não precisa de um servidor central : qualquer pasta do seu computador pode ser usada como repositório, para que você possa brincar com o git e fazer seus testes offline. Você pode inicializar um repositório e simular três colaboradores em outras três pastas sem enviar um bit na rede. Isso ocorre porque qualquer cópia clonada do repositório é um repositório completo com o qual você pode se comprometer. Isso é bom se você deseja trabalhar em um voo entre EUA, China ou Europa.

O Google Documents ( https://docs.google.com ) fornece ótimas ferramentas para criar documentos juntos (incluindo edição em tempo real). Ele armazena tudo online para você e se integra bem à sua conta do Gmail. Por padrão, o Google Docs não tem compatibilidade com LaTeX, mas você pode habilitá-lo aqui:

http://docs.latexlab.org/

Não sei ao certo como funciona para reversão, mas tenho certeza de que há um recurso para isso. Ouvi falar de algumas pessoas que usam o plug-in LaTeX do Google Wave para elaborar esboços preliminares de documentos.

Eu faço meus coautores aprenderem Mercurial, e eu costumava fazê-los aprender Subversion. Se você é um fã do Subversion, basta ler isso , é tudo verdade.

Não importa qual sistema você use, a coisa mais difícil é levar a outra pessoa a instalar o software e começar a usá-lo. O Skype é a solução perfeita. As versões recentes do Skype permitem o "compartilhamento da área de trabalho", o que realmente ajuda quando você deseja liderar seu co-autor através do procedimento de instalação. E usei o compartilhamento direto da área de trabalho combinado com o Skype para escrever um artigo com meu co-autor. Funciona muito bem.

O que é realmente necessário é um "Github para cientistas". Algo que fornece um repositório, tem controle de versão, edição colaborativa, etc. Adivinhe, existe http://www.scribtex.com/ .

aqui está um novo editor de látex colaborativo online chamado WriteLatex que parece promissor, como um balcão único para muitas necessidades / exigências de redação científica.

• funciona no celular
• tem visualização em tempo real
• compartilhamento fácil / privado
• encontra erros de látex
• permite adicionar bibliotecas / estilos de látex
• armazenamento na núvem

o co-autor John Hammersley postou um anúncio no tcs se meta aqui e ele responde ao feedback (mais 5 votos no anúncio e ele aparecerá no site principal). parece que pode evoluir para uma ferramenta valiosa para a comunidade tcs ao longo do tempo e talvez os autores possam implementar alguns recursos populares especificamente sob solicitação.

E sistemas simples, soluções:

• Google Docs, escritor Zoho ... e outras ferramentas colaborativas.
• O Dropbox lida com situações em que duas pessoas tentam confirmar alterações no mesmo arquivo. A segunda pessoa de confirmação recebe seu arquivo renomeado (X.txt -> X.txt_blabla ...) e o arquivo original (X.txt) atualizado com a versão mais recente. Mais informações em: Ajuda do Dropbox: "O que acontece se duas pessoas alteram o mesmo arquivo?"

Está fora de questão, mas às vezes há situações em que parte do grupo é capaz de soluções simples como SVN, enquanto outra parte do grupo é capaz de controle de versão distribuído como o GIT. Em tais situações, a cooperação é possível:

• git-svn - Operação bidirecional entre um repositório do Subversion e o git
• Git - Curso de Bater SVN
• Usando efetivamente o Git com o Subversion

Eu descobri recentemente o sharelatex.com e o usei com meu colaborador para coautor de um artigo. Gostei tanto que meu plano atual é usá-lo em todos os meus projetos. Alguns recursos notáveis:

• TeXing no navegador em tempo real (como o Google Docs, mas criado para TeX, com destaque para sintaxe e tudo).

• Compilação no navegador e visualização de PDF

• Suporta projetos com vários arquivos

• Possui um recurso de histórico

• Sincroniza com o Dropbox (que será lançado publicamente em breve, a partir de seu status beta atual). Dessa forma, você pode transferir o salvamento de backups etc. para o Dropbox. Dependendo de como é feito, isso também deve permitir que você use sharelatex, mesmo que seus co-autores não o desejem, desde que estejam dispostos a usar o Dropbox para compartilhar arquivos.

• Você pode fazer o download / upload do seu projeto a qualquer momento, para não ficar preso ao sharelatex se algo der errado ou você mudar de idéia ou o que for.

A única desvantagem (mas acho que vale a pena): embora o uso do sharelatex seja gratuito, alguns de seus recursos não são. Notavelmente, para usar o Dropbox sync (quando ele for lançado), ou se você quiser que mais de 6 coautores trabalhem no mesmo projeto sharelatex, terá que pagar US $ 8 / mês. ou US $ 80 / ano [em abril de 2013]. No entanto, uma vez que eles lançam a sincronização do Dropbox, parece um preço muito justo para mim.

[Isenção de responsabilidade: não tenho nenhum relacionamento com a sharelatex ou com seus funcionários que não seja o uso do produto.]

SVN é a ferramenta desenvolvida para esse fim. Eu me esforçaria para aprender. Não é mais complicado do que aprender a usar, digamos, o pacote de algoritm2e Latex ou um dos pacotes de latex criador de slides em pdf.

Dito isto, eu uso o CVS em vez do SVN. Existe um suporte melhor dos administradores de CS em nossa instituição (o servidor SVN é mais gerenciado pelo usuário). Além disso, eu aprecio que os arquivos de versão subjacentes ainda estejam lá e editáveis ​​se algo der muito, muito errado.

Existem 2 desvantagens quando comparado ao SVN. Renomear arquivos não é tão bom, mas posso conviver com isso (escolha um bom nome na primeira vez). O segundo problema é que é preciso uma conta CS local para acessar o repositório. Portanto, a partir de outra instituição, o acesso só é possível se uma conta for criada primeiro. É claro que não espero que seja um problema real em nenhum lugar; um membro do departamento local provavelmente pode patrocinar essa conta.

A restrição de acesso local se deve ao fato de os administradores não quererem suportar um pserver. (Mais difícil de proteger, etc.)