Alternativas ao controle de versão profissional [fechado]

Estamos trabalhando em parceria com alguns não programadores (escritores) que precisam contribuir com um de nossos projetos.

Agora eles simplesmente não gostam da idéia de usar o Git (ou qualquer outra coisa) para controlar o seu trabalho. Eu acho que isso ocorre porque eles simplesmente não acham que vale a pena envolver-se com os conceitos distorcidos do controle de versão. (quando eu os introduzi pela primeira vez em ramificação e fusão - eles pareciam que eu os estava ofendendo.)

Agora, não estamos em condições de educá-los ou convencê-los a usá-lo. Estamos apenas tentando encontrar alternativas para obter todo o trabalho deles com versão (que é o que precisamos) - e eles obtêm um fluxo de trabalho fácil e se concentram no que fazem.

Eu vim com algumas idéias ...

• diga a eles para salvar seu trabalho como um arquivo separado sempre que fizerem alterações não triviais e, em seguida, use um diff do nosso lado para rastrear as alterações.
• escreva um programa (em Python) que implemente os "marcos" no CSSEdit de alguma maneira.

Sobre o projeto:

É um sistema de processamento de linguagem natural (escrito em C + Python). Contratamos alguns escritores para preparar contribuições para o sistema em diferentes idiomas. E à medida que desenvolvemos o software, precisaríamos desses escritores para fazer alterações em suas entradas (artigos). Às vezes, as mudanças são muito pequenas (uma ou duas palavras) e outras, grandes.

A razão pela qual precisamos controlar a versão dessas mudanças é porque todas as pequenas / grandes mudanças na entrada têm o potencial de alterar drasticamente a saída do sistema.

quando eu os introduzi pela primeira vez em ramificação e fusão - eles pareciam que eu os estava ofendendo

Provavelmente, porque ramificação e mesclagem são conceitos avançados e infinitamente menos úteis do que simplesmente acompanhar as alterações.

Então, por que não explicar apenas "confirmar" (salvar) e "atualizar"? Dois conceitos realmente simples . Tenho certeza que você pode explicar em menos de 10 minutos.

Se você realmente deseja usar ramos separados e coisas assim, você mesmo pode fazer essa parte sem envolvê-los.

Uma abordagem pouco ortodoxa seria apenas usar o Dropbox . Peça aos autores que salvem os arquivos no diretório dropbox e obtenha versões e backups gratuitamente. Além disso, basicamente não há curva de aprendizado para os autores.

Para o git, parece que, no final, você acabará fornecendo aos autores as versões corretas das ramificações de qualquer maneira, basta colocar o repositório git na caixa de seleção e lidar com as ramificações e mesclagens dos autores.

Sinceramente, a resposta está na sua edição: "Contratamos alguns escritores" - às vezes você só precisa ter uma mente ensangüentada ... eles querem seu dinheiro, têm que fazer o que você deseja, desde que o que você queira não seja irracional.

O argumento que você argumenta é o argumento que você já avançou - precisamos ser capazes de fazer X, Y e Z para fazer o produto funcionar - e , para fazer isso , precisamos que você faça isso. Seremos o mais solidários possível, mas, para que isso funcione (e, portanto, continue como um fluxo de renda para você, o escritor), isso tem que acontecer.

Costumo concordar que uma solução apropriada baseada em Wiki parece ser uma boa combinação - mas o desafio aqui é como encontrar um compromisso entre o fluxo de trabalho e os requisitos.

Vou repetir o ponto-chave - para que seu projeto seja um sucesso você precisa os artigos a serem versionadas, portanto, aqueles que trabalham nos artigos tem que jogar por um conjunto acordado de regras, se isso não acontecer você vai ficar queimados e, por extensão, os escritores também.

Eu tive que lidar com uma situação semelhante como essa antes. No final, acabamos de designar um desenvolvedor (eu) como o ponto de contato de controle de versão para terceiros.

O terceiro me enviava um e-mail com um arquivo zip dos arquivos do projeto todos os dias e eu fazia o check-in para eles. Eu configurei uma área de trabalho de projeto separada e a conta svn para eles e descompactaria os arquivos nessa área de trabalho, substituindo o que estava lá e depois fazendo o check-in nessa conta.

Não era a coisa mais divertida de se fazer todos os dias, mas às vezes é mais importante concluir o trabalho.

Uma vantagem é que isso me ajudou a revisar o trabalho deles para garantir que eles não estivessem verificando códigos e dados incorretos que quebrariam a compilação.

O SparkleShare é um clone do dropbox baseado em git, acho que atende às suas necessidades.

SparkleShare cria uma pasta especial no seu computador. Você pode adicionar pastas hospedadas remotamente (ou "projetos") a essa pasta. Esses projetos serão automaticamente sincronizados com o host e com todos os seus pares quando alguém adicionar, remover ou editar um arquivo.

... aqui estão alguns exemplos do que faz bem e menos bem com carinhas:

Ótimo

• Alteração frequente dos arquivos do projeto, como texto, documentos do escritório e imagens
• Rastreando e sincronizando arquivos editados por várias pessoas
• Revertendo um arquivo para qualquer ponto do histórico
• Impedindo a espionagem de seus arquivos no servidor usando criptografia

Não é tão bom

• Backups completos do computador
• Armazenando sua coleção de fotos ou músicas
• Arquivos binários grandes que mudam com frequência, como projetos de edição de vídeo ...

Atualização (novembro de 2015) : o projeto parece ter sido abandonado (última versão a partir de abril de 2014).

Se você pode fornecer espaço de trabalho preparado com uso transparente de VCS, eles usarão VCS. Não ensine não programadores a usar o VCS à maneira do programador

Basta encontrar o editor com suporte VCS incorporado, configurá-lo e mostrar etapas fáceis adicionais em seus trabalhos.

Apenas um exemplo - o Editplus conhece o Subversion, tem capacidade de executar operações básicas de SVN dentro da janela do editor. O Editplus mais recente ainda pode usar o TortoiseGIT para integração com o Git

Edit : encontrou uma solução alternativa: EasySVN , que, sendo configurada corretamente, monitora a cópia de trabalho e realiza a confirmação automática e a troca automática, permitindo o uso de qualquer ferramenta de autoria para o usuário final e para qualquer formato de documento

Que tal configurar um WebDAV ?

Ele manipulará automaticamente o histórico de versão em linha reta para eles. Tudo o que eles precisam fazer é conectar-se ao servidor como se fosse uma unidade de rede e cada salvamento será uma confirmação.

documentos Google

O Google Docs pode fazer o que você deseja. File > See Revision Historypermitirá acompanhar as alterações.

Você também tem o problema de entregar e receber arquivos de graça; basta compartilhar o documento entre todos.

Finalmente, é fácil de usar; os escritores nem precisam saber que há versões acontecendo.

Agnóstico do SO

Escreva um programa Python que você pode arrastar e soltar um arquivo para, esse programa pode então fazer o git adde git commite não o que e eles nunca tem que lidar com isso.

ou

Use um sistema de arquivos baseado no WebDav que você possa montar na máquina e que o servidor faça as gitcoisas de forma transparente.

OSX / Linux

Escreva um plugin FUSE baseado em Python que pegue os arquivos e os comprometa com o git. Depois, eles podem simplesmente abrir e salvar o sistema de arquivos montado de forma transparente. Existem alguns recursos do FUSE para Windows , mas provavelmente nem vale a pena brincar.

janelas

Você pode escrever algum código para usar os Drivers de Filtro do Sistema de Arquivos para fazer as gitcoisas de forma transparente .

Ah, as alegrias dos não-codificadores brincando. Eu sugeriria a criação de um ambiente git / mercurial para eles. Diga a eles para salvar tudo em um formato que o repositório possa manipular. Com tortoisegit ou tortoisehg , eles não precisam saber como o repo funciona. Eles apenas verificam se têm um ponto de exclamação no diretório do projeto, clique com o botão direito do mouse no arquivo incorreto e clique em confirmar. Digite uma sinopse das mudanças (são escritores, certo?) E pronto!

Uma etapa extra no fluxo de trabalho para eles, mas nada sobre fusão / ramificação / coisas legais. O ambiente pré-construído já está configurado para estar no ramo dos gravadores, para que eles não vejam código. Faça com que um script os sincronize automaticamente todos os dias. Mais tarde, depois que eles estiverem acostumados a confirmar, você poderá mostrar a eles recursos extras. A capacidade de ver o que mudou quando é tão útil que eles não conseguirão ficar sem isso, depois que você o introduzir no fluxo de trabalho.

E o Share Point? Eu sei que não é popular nos mundos do desenvolvimento, mas se seus escritores estiverem usando o Windows como sistema operacional, eles funcionarão bem e eles realmente não saberão que estão usando o controle de versão (uma grande vantagem para o meu trabalho).

Essa solução também os impede de lidar com qualquer coisa que os assuste muito, pois parece que eles são nervosos com coisas novas.

Você poderia configurar uma ferramenta que monitore o sistema de arquivos em que os gravadores estão salvando seus arquivos e faça com que ela seja executada automaticamente sempre que salvar?

Se você o colocar em um compartilhamento de rede, poderá fazer toda a configuração sem envolvê-los; mas toda vez que eles fornecerem uma versão atualizada para sua equipe usar, ela será adicionada ao git para você.

Você olhou para o Plastic SCM. Eles estão tentando simplificar o uso

Se você deseja apenas backups com versão, use o Dropbox ou configure o serviço de backup do Windows. Ou você pode instalar o Crashplan ou outro produto similar.

Para o Mercurial DVCS, existe uma interface de usuário chamada EasyMercurial , cujo objetivo declarado é explicitamente fornecer uma visão simples das operações básicas de controle de versão.

O EasyMercurial deve ser:

• simples de ensinar e aprender indicativo do estado real do repositório, usando uma representação gráfica do histórico
  • reconhecidamente perto do fluxo de trabalho normal da linha de comando para o Mercurial consistente entre plataformas

Não estamos tentando produzir "o melhor" cliente Mercurial para nenhum propósito. Incentivamos ativamente os usuários a migrar para outros clientes à medida que suas necessidades evoluem. O objetivo é simplesmente fornecer algo acessível para iniciantes em pequenos grupos de projetos que trabalham com um repositório remoto compartilhado.

Eu recomendaria tentar.

Eu tive que trabalhar com não programadores muitas vezes (principalmente artistas gráficos, e se seus escritores têm a menor idéia de como gerenciar arquivos de trabalho como artistas, então você está pronto para ... hum ... divertido .. .). Existem três abordagens possíveis:

1. Finja que são programadores, tente ensiná-los a usar o controle de versão. Isso não vai funcionar e você terá brigas constantes.
2. Escreva para eles uma ferramenta muito simples que pegue a versão atual e a cole em algum lugar para que eles possam voltar aos arquivos de ontem, se necessário. Isso é possível, e fiz isso para uma equipe de criadores de DVD (criando menus, gráficos, todo tipo de coisa) há muitos anos com algum sucesso: a ferramenta que escrevi foi um invólucro de um clique para o PkZip (você pode ver que isso era há pouco tempo) e apenas compactou o diretório de trabalho e nomeou o arquivo para a data + hora.
3. Assuma o controle do que eles produzem a si mesmo. Deixe claro que seus arquivos precisam ser entregues a um programador e somente se tornar parte do projeto quando o programador aceitar os arquivos: o programador os verifica no controle de versão e o conteúdo é gerenciado de maneira profissional.

Pessoalmente, acho que a opção 3 é o caminho a percorrer. Isso significa um pouco de dor e irritação para quem precisa pegar as entregas de arquivos e fazer o check-in, mas muito menos do que qualquer outra opção.

Eu também diria, esteja ciente de que os não programadores entregarão arquivos com qualquer nome de arquivo antigo que você possa imaginar. As convenções de nomenclatura são estranhamente estranhas para elas. Eles fornecerão um arquivo chamado "Imagem" ou algo assim e, quando você contar as coisas erradas, o arquivo será "Picture_Final", que corrigiu apenas cerca de três falhas. Quando você apontar isso, obterá outro arquivo, chamado "Picture_NewFinal" e, em seguida (se tiver sorte), "Picture_NewFinal2", embora seja possível que, nesse momento, eles descartem qualquer senso de desenvolvimento histórico e o chamem de "Spanner Icon coisa".

Novamente, você pode tentar aplicar uma convenção de nomenclatura, o que significa dizer a eles com antecedência como cada arquivo deve ser chamado, ou você pode passar horas decifrando e renomeando o que eles enviam a você. Aqui, eu diria que você deseja a planilha para sua própria sanidade, então tente fazê-las seguir: simplesmente não se surpreenda quando não o fizerem.

Espero que ajude - divirta-se!

Se houver alguma chance de que dois deles precisem trabalhar no mesmo destino de uma só vez E se você puder lidar com todo o trabalho deles em arquivos de texto, tentarei compartilhar documentos do Google.

Tem uma incrível capacidade de multi-editor / colaboração - de longe o melhor que eu já vi. Eles também têm versão completa e podem ser exportados como arquivos de texto.

Mas esses são dois grandes ses.

Deixe-os trabalhar em uma pasta, salvando arquivos como de costume.

Uma vez por dia (ou semana, etc), copie o conteúdo dessa pasta para backup_dd_mm_yyyy A maioria dos códigos-fonte dos sistemas ocupa uma quantidade trivial de espaço, considerando o espaço disponível atualmente.

A cópia pode ser feita por você, por terceiros, por uma ferramenta ou por um script.

Isso limita a perda a um dia, dá uma história, é transparente para eles.

Não é perfeito para nenhuma das partes, mas uma resposta que busca atingir um meio termo.