alterações de código de mesclagem sem controle de origem verdadeira

Question

Temos alguns desenvolvedores que trabalham na mesma solução VS2005, mas o nosso controle de origem é muito ruim. (Nossa empresa utiliza colheita, que nós damos um voto de confiança).

Agora, todos nós estamos apenas trabalhando fora dos arquivos em uma unidade lan compartilhada. Obviamente, isso causa alguns problemas. Mas nós pensamos que é melhor do que trabalhar localmente, e rastrear os arquivos que tocou em uma planilha e fundindo tudo manualmente. Alguém tem uma estratégia para fundir nossas mudanças?

Alguns dos problemas existem por causa da beaurocracy corporativa (como a obrigatoriedade da colheita). Essas mesmas políticas prevenir a introdução de novas ferramentas em nosso ambiente. Assim, as estratégias que a compra de evitar / download de um novo software iria funcionar melhor para nós.

Answer 1

Trate o compartilhamento como se fosse o seu sistema de controle de origem. Tornar o compartilhamento somente leitura, que vai forçar os desenvolvedores a obter cópias locais, a fim de fazer alterações. Você então tem uma versão um pouco estável para comparação. Isso ajudaria a facilitar a ser capaz de fazer "fusões". "Verificar" código teria que consistem em algum tipo de estratégia de backup para o arquivo (possivelmente fazendo uma cópia do arquivo com um timestamp e nome de usuário como parte do novo nome de arquivo) e substitui o original com a nova versão.

Dito isto, fazer este tipo de atividade sem um sistema de controle de origem real que é de confiança vai ser difícil e propenso a erros.

Answer 2

Aprenda a usar Colheita. É preciso um pouco de esforço para fazer as coisas indo bem, mas no geral é um sistema de controle de origem excelente.

Answer 3

Outra possibilidade seria Beyond Compare da Scooter . Tem dois e três merge caminho e grande funcionalidade diff em arquivos e diretórios. Se você quer saber um pouco mais sobre ele, ouvir o delphi Podcast por Jim McKeith .

Mas como a maioria dos outros que eu recomendaria para qualquer uso Git ou aprender Harvest.If o sistema de controle de origem permite alterar a sua aplicação diff, Beyond Compare seria um excelente substituto.

Answer 4

Get git e instalá-lo localmente na máquina de cada desenv. Em seguida, defina os repositórios de replicar.

Answer 5

Há duas questões distintas: controle de versão e concentração. Não há absolutamente nenhuma desculpa para não usar um sistema de controle de versão. Se a empresa decidiu sobre uma solução (por qualquer motivo), então usá-lo. Não gostando ou não "ter confiança" não é uma razão válida para não usá-lo. E usando uma unidade compartilhada ao sistema de controle de código fonte um mímico está além de louco.

A fusão é uma segunda questão. Você simplesmente precisa de uma ferramenta diff / merge. Escolher um. Como você ter ido tanto tempo sem um ?!

Araxis é um grande. Custa alguns dólares. O pessoal SourceGear foram distribuir livremente sua ferramenta de comparação / merge por algum tempo (aquele que vem com Vault). É também um forte concorrente. Esses são dois que eu usei que eu sei que ainda estão no mercado agora. Há outros alguns já mencionados.

Mesclando tudo à mão não é uma solução sustentável. Combinando isso com não usando um VCS é uma receita para o desastre.

Answer 6

Você provavelmente vai ter que baixar alguma coisa a menos que queira fazê-lo com a mão. Eu recomendo Winmerge . É gratuito, open source, e provavelmente melhor para você um pequeno download que não baralhar as coisas.

Answer 7

Há um unix ferramenta de linha de comando chamado merge padrão que será bastante inteligente mesclar dois conjuntos de alterações para um arquivo. A sintaxe é:

merge mine older yours

Onde "meu" é o arquivo com as alterações, "mais velho" é o arquivo original, e "seu" contém alterações de outra pessoa.

Não tenho certeza se você tem um UNIX (ou Mac OS X) caixa em torno de mentir para fazer isso em embora.

Answer 8

Isto pode não ser uma opção viável, mas talvez você poderia usar um sistema distribuído como bazar , < a href = "http://git.or.cz/" rel = "nofollow noreferrer"> git , ou Mercurial .

A razão eu sugiro que estes é que eles são muito baixa sobrecarga e pode ser usado com outros sistemas. Eu sei com bazar do repositório é simplesmente uma pasta oculta adicionado ao diretório.

Answer 9

Trabalhando fora de uma unidade compartilhada não é uma boa idéia, e tem o meu voto de "não confiança".

Seria muito fácil de substituir as alterações de outros, você não tem o controle de alterações, nenhuma maneira de ramificação ou tag / etiqueta, etc.