No controle de versão centralizado, é sempre bom atualizar com frequência?

9

Assumindo que:

Sua equipe está usando o controle de versão centralizado.
Você está trabalhando em um recurso maior, que levará vários dias para ser concluído, e não poderá confirmar antes disso, porque isso interromperia a compilação.
Os membros da sua equipe confirmam algo todos os dias que pode alterar alguns dos arquivos nos quais você está trabalhando.

Como esse é o controle de versão centralizado, você terá que atualizar seu checkout local em algum momento: pelo menos uma vez antes de confirmar o novo recurso.

Se você atualizar apenas uma vez antes do seu commit, poderá haver muitos conflitos devido a muitas outras alterações feitas por seus colegas de equipe, o que pode ser um mundo doloroso para resolver de uma só vez.

Ou, você pode atualizar com freqüência e, mesmo que haja alguns conflitos para resolver dia a dia, deve ser mais fácil, pouco a pouco.

Você prefere atualizar sempre?

svn version-control cvcs

— janos
fonte

16

Se você não está ramificando, não está aproveitando um dos maiores benefícios de um sistema de controle de versão .

— gahooa 3/09/12

Seu CVCS fornece uma visualização conveniente de possíveis conflitos de atualização sem modificar seus arquivos locais? O TortoiseSVN tem essa funcionalidade.

— Rwong 04/04/12

discutido anteriormente: Com que frequência devo / você faz confirmações? e git / outro VCS - com que frequência cometer?

— Gnat #

@gnat a questão é quantas vezes a atualização, não cometer

— Janos

2

A pergunta é muito específica sobre quantas vezes "atualizar". E isso já faz parte das suposições que seus colegas de equipe cometem de fato com frequência. O que certamente é uma coisa boa, mas, de qualquer forma, não é o assunto aqui.

— janos 04/04/12

24

Pessoalmente, atualizo minhas versões locais diariamente.

No cenário que você descreve, eu iria além por

Criando uma ramificação para o novo recurso longo.
Mesclar frequentemente da linha principal para este novo ramo.

Deste jeito,

Você pode fazer check-in diariamente para preservar seu código no servidor
Você não precisa se preocupar em interromper a compilação ao fazer o check-in.
Você pode usar o repositório para desfazer algum trabalho ou diferenças quando necessário com check-ins anteriores.
Você certamente está trabalhando na base de código mais recente e detecta possíveis alterações de código conflitantes desde o início.

As desvantagens que eu vejo são

A mesclagem do main deve ser feita manualmente (ou com script)
É preciso mais "administração"

— Lieven Keersmaekers
fonte

2

Você tem razão em que é sempre bom trabalhar em ramificações de recursos em vez de no tronco. O problema é que a maioria dos CVCS faz um mau trabalho na mesclagem; portanto, a maioria dos programadores que conheço no CVCS se concentra em uma única ramificação na maioria das vezes. A questão é: você pode dizer a eles que, em geral, é sempre bom atualizar com frequência?

— janos 03/09/12

6

Vindo do Sourcesafe (onde não mesclamos nada) ao TFS, git e mercurial (onde costumamos mesclar frequentemente) , minha experiência pessoal é que a mesclagem geralmente cria muito menos problemas do que esperar por uma mesclagem do big bang. Concordo que isso requer uma mudança de mentalidade dos colegas programadores. Estou parecendo um disco quebrado no meu local de trabalho, mas todos devem se comprometer com frequência e atualizar com frequência.

— Lieven Keersmaekers #

6

Sim, é uma boa ideia atualizar com frequência. Você atualiza com frequência para evitar conflitos de mesclagem difíceis e este é o básico do conhecimento do Gerenciamento de Configuração de Software (SCM) com o problema de alterações divergentes.

Isto é independente se é centralizado ou distribuído; quanto mais tempo você diverge de uma fonte upstream (ou seja, se é um tronco, filial ou outro repositório no caso DVCS), maior a chance de conflitos de mesclagem. Sim, surpresas desagradáveis da sua equipe podem surgir durante a atualização, mas adiar a surpresa desagradável é ainda pior (quanto mais você espera, menos pessoas se lembram do porquê de um conjunto de alterações).

Para que a atualização funcione, isso também significa que você e outros programadores que trabalham com código nunca devem confirmar ou enviar conscientemente o código upstream que interrompe a compilação . Geralmente, é por isso que os programadores se ramificam (ou divergem do upstream em termos de SCM), para proteger os membros de sua equipe e outras partes interessadas de terem código quebrado, caso tal situação inevitavelmente aconteça.

O mantra que você pode usar para lembrar é o seguinte: "atualizar, atualizar, atualizar, confirmar". Sempre verifique se suas alterações funcionam com outras pessoas antes de confirmar. Isso também é para garantir que a verificação do código pela primeira vez também funcione.

— Spoike
fonte

4

O terceiro ponto da pergunta está simplesmente errado :

Você está trabalhando em um novo recurso que certamente levará vários dias para ser concluído e não poderá confirmar antes disso, pois isso interromperia a compilação.

Se você sabe que vai trabalhar em algo que não pode confirmar por algum tempo, esse é o exemplo de manual para o uso de ramificações.

Não se coloque na situação em que há muitas alterações pendentes. Se você sabe que não poderá confirmar na ramificação principal do seu projeto por algum tempo, trabalhe em outra ramificação. E aí, cometer com frequência .

Se você já está na situação descrita na pergunta, mude para um ramo agora , confirme suas alterações e continue trabalhando nesse ramo.

Normalmente no CVCS, é uma boa ideia atualizar com frequência. Mas se você estiver trabalhando em uma ramificação, a questão de "atualizar com frequência ou não" se tornará "mesclada com frequência ou não". E a resposta é sim de qualquer maneira. Certifique-se de confirmar todas as alterações pendentes (na ramificação) antes de mesclar a partir de outra ramificação, para sua opção de reverter a mesclagem com segurança, se necessário.

— janos
fonte

2

Eu acho que você deveria se comprometer mais vezes. Se você vai trabalhar por um longo período de tempo, como alguns dias, deve ramificar seu código e trabalhar em sua ramificação, em vez de trabalhar diretamente no tronco. Eu sei que é conveniente começar a trabalhar sem ramificações, mas não é realmente flexível, pois você não pode ter certeza de que sua atualização / confirmação quebraria seu código ou não, o que acaba na situação em que você manterá sua atualização / confirmação até que você fez o seu trabalho. A "ramificação de recursos" é melhor na maneira em que você sempre pode confirmar seu código e apenas voltar mais tarde quando terminar.

Na estratégia de ramificação, a atualização é substituída pela mesclagem do tronco. Pela minha experiência, você não precisa mesclar do tronco com tanta frequência, pois o código em algo como um período de cinco dias não mudaria muito e é mais fácil resolver o conflito apenas uma vez quando você terminar.

— tia
fonte

1

Na verdade, acho mais conveniente usar um controle de versão distribuído localmente. Ou seja, eu uso o git como cliente do subversion. Isso tem as vantagens de que:

As alterações locais são salvas antes da atualização; portanto, se eu cometer um erro na mesclagem, sempre posso voltar e fazê-lo novamente.
Ao fazer alterações maiores, posso salvar as peças que estão concluídas. Isso facilita a revisão das alterações restantes em andamento.
Quando eu conserto um bug durante algum trabalho maior, posso confirmar apenas essa correção, confirmar temporariamente o restante e "confirmar" a correção para o subversion, mantendo o outro trabalho em andamento local.

— Jan Hudec
fonte

0

Se você estiver adicionando um novo recurso, poderá criar um novo arquivo de origem único (e um arquivo de cabeçalho de interface externa correspondente)?

Estou preocupado que um "novo recurso" esteja tendo implicações generalizadas? A orientação a objetos pode não ser mais a palavra da moda, mas há mérito nesse paradigma.

Dessa forma, você pode criar a estrutura (interface externa, mais funções de stub) e confirmar que haverá efeitos mínimos de terceiros, enquanto termina o resto do seu desenvolvimento?

Na situação que você descreve, sinto que é melhor ter mais arquivos de origem menores do que arquivos menores.

— Andrew
fonte

0

Qual a diferença entre um controle de versão centralizado e um distribuído?

Nos dois casos, você deverá fazer check-in em um local cujo conteúdo será movido em comparação com o que você iniciou. Não vejo diferença na frequência de mesclagem do repositório central para o local de trabalho (e a ramificação do projeto é o local de trabalho).

Costumo ser do jeito que costuma ser mesclado (pelo menos uma vez por dia, também posso mesclar em outro momento conveniente para mim ou quando sei que alguém fez check-in em algo que afeta o que estou trabalhando). É muito mais fácil absorver pequenas alterações e, se você tiver um problema, as pessoas são mais úteis quando você pergunta sobre o que acabaram de fazer o check-in do que sobre o que fizeram o check-in há uma semana.

BTW, eu não sei o que você chama de "quebrar a compilação". Costumo trabalhar em um incremento relativamente pequeno, para manter um estado compilável, mesmo que ele quebre alguns recursos. E executo os testes para saber que a mesclagem não quebrou algo que deveria ter funcionado. Novamente, é mais fácil corrigir um problema quando ele é detectado cedo.

— AProgrammer
fonte

2

Na versão distribuída, você pode confirmar suas alterações pendentes localmente. Dessa forma, se uma mesclagem resultar em muitos conflitos e você preferir adiar e reverter, é possível. No controle de versão centralizado, você não pode confirmar localmente e, se quiser reverter uma atualização, não poderá. Portanto, a nuance da versão centralizada é importante, porque a operação de atualização é mais arriscada do que uma mesclagem.

— janos 03/09/12

3

@ janos, Na minha experiência, quanto mais difícil a mesclagem, mais você deseja fazer isso agora, pois a espera nunca será mais fácil. Eu costumo folhear as diferenças antes de aplicá-las e às vezes faço um backup manual, se elas parecerem complexas. O que também fiz foi usar um repositório mercurial para controlar a versão das alterações que não pude verificar no sistema oficial. Não achei que os benefícios justificassem o custo na minha situação, mas pode ser diferente para o seu.

— AProgrammer 03/09/12

a operação de atualização no CVCS é menos segura porque você não pode revertê-la da maneira que pode reverter uma mesclagem no DVCS. É por isso que a parte CVCS é significativa e a questão faria pouco sentido em um DVCS.

— janos 03/09/12

A espera não pode diminuir a dificuldade nem o risco; portanto, você está discutindo por atualizações mais frequentes.

— AProgrammer 03/09/12

Sim, sempre achei bom atualizar com frequência. Quero validar que, procurando coisas ruins, posso não pensar em mim. Por exemplo, se você tem um grande refatorador pendente, talvez não queira nem mesmo pequenos conflitos surgindo em seu rosto. Eu não sei. Eu só quero ter certeza de que posso continuar dizendo "atualize com frequência" sem fazer nada.

— janos 03/09/12

0

Depende de quão bom você é "não atualizado" quando alguém quebra a compilação. Por um lado, você deseja atualizar os menores pedaços possíveis. Pessoalmente, eu atualizo quase sempre que noto que há atualizações disponíveis. Por outro lado, se a construção for interrompida e levar um dia para outra pessoa consertá-la, você ainda poderá trabalhar em seu novo recurso nesse meio tempo.

Eu trabalhei com sistemas de controle de versão que são muito difíceis de fazer backup quando uma atualização é concluída. Nesses, costumo atualizar apenas antes de fazer o check-in. Com melhores sistemas de controle de versão, há poucas razões para não atualizar várias vezes por dia.

— Karl Bielefeldt
fonte