confusão entre SVN e backup de código por mês / data / hora sempre que eu fizer atualização importante ou importante para o código

4

Estou trabalhando em dois projetos diferentes simultaneamente, sempre que as alterações forem feitas, usamos

  1. Tortoise SVN para o projeto A
  2. Backup por pasta do Projeto B (isso é feito por mim no meu sistema)

Acho o SVN bom para manter a última máquina do servidor de código e atualizá-lo sempre que necessário.
Para o Projeto A, por acaso faço muitas mudanças no projeto A e sou aconselhado a não cometer as alterações repetidas vezes, mas apenas uma grande mudança de uma só vez.
Mas, como não estou sozinho no projeto A, costumo fazer backs de código por pasta toda vez que faço uma alteração importante para poder voltar e retornar se ocorrer algum conflito.

Mas o que devo fazer no caso do projeto B?
onde mais estou no projeto (a partir de agora).
Devem ser SVN ou backups de pastas?

A razão pela qual eu faço backups de pasta para o projeto B é que você às vezes, a compilação dada ao cliente falha / buggy, em vez de fazê-los aguardar a correção Eu simplesmente abro e abro o projeto e compilo o último build de trabalho e dou o executável para que ele possa continuar seu trabalho e não esperar que eu o conserte (pode demorar muito).

Estou trabalhando com o Delphi em ambos os projetos.

    
por PresleyDias 14.12.2011 / 10:46
fonte

4 respostas

19

im advice not to commit the changes again and again but just a major change all at once

É um conselho errado .

project B where most im on the project (as of now) should it be SVN or folder backups

Você deve usar o controle de versão em qualquer projeto.

Backups e controle de versão não são a mesma coisa, embora um repositório externo (centralizado ou distribuído em outro computador) seja um backup em si mesmo e backups (por exemplo, pastas datadas ou arquivos zip) junto com alguma ferramenta diff (por exemplo, WinMerge ) poderia servir como uma ferramenta de controle de versão muito rudimentar. Mas como os excelentes sistemas de controle de versão estão disponíveis gratuitamente, não há absolutamente nenhuma desculpa para não usá-los.

É claro que os backups devem ser feitos além para usar um sistema de controle de versão.

    
por 14.12.2011 / 11:00
fonte
10

The reason I do folder backups for the project B is that sometimes the build given to the client fails/buggy so instead of making them wait for it to fix I just go and open the project and compile the last working build and give the executable

Este é precisamente o problema que o controle de origem deve resolver (usando ramificações / tags). Você faria um favor a longo prazo, mudando para o SVN. Você vai perceber o quão sábio tal movimento foi (teria sido) a primeira vez que você precisa fornecer um hotfix para um bug em uma versão mais antiga, enquanto você está no meio do desenvolvimento de um novo recurso na versão mais recente, que não deve ser implantado ainda. Com o SVN, a fusão entre diferentes filiais é muito mais fácil e segura do que o manual diff & mesclar entre diferentes diretórios de backup.

    
por 14.12.2011 / 11:35
fonte
4

Você pode mudar para o mercurial (controle de versão distribuída). Dessa forma, você pode confirmar quantas vezes quiser (em ambos os projetos).

No projeto A, uma vez que você tenha atingido uma massa crítica de commits que são aceitáveis, você pode empurrá-los para o repositório do subversion (usando o HgSubversion *). Se o número de commits for um problema, você pode usar as filas do mercurial (Tutorial ) ou faça uma pequena correção caseira reescrevendo todos os seus commits em um. Por exemplo, exporte-os todos como patches - facilmente feitos com o TortoiseHg - e depois importe-os para o repositório novamente. Em seguida, confirme e você terá todas as alterações em um commit.

* Para usar o HgSubversion você precisa das ligações do SVN do Python. No TortoiseHg (cliente do Windows Mercurial) eles estão incluídos, então basta fazer o download da fonte do HgSubversion, incluir o caminho no arquivo hgrc e estar pronto para ser usado.

    
por 14.12.2011 / 11:50
fonte
1
  • Use um repositório de origem para todos os seus projetos, como escreveu @JoonasPulakka e @ PéterTörök.
  • Faça backup de todo o repositório de origem diariamente em outro servidor / unidade. Corrupção / perda de repositórios de origem pode acontecer, e é a única maneira de recuperar todo o histórico de suas mudanças, não apenas a última versão. Há uma pergunta sobre SO em qual é a melhor maneira de fazer backup um repositório SVN .
  • Etiquetar / ramificar suas alterações menores / principais. Se uma dessas compilações for liberada para o cliente e falhar, você poderá corrigir essa ramificação, liberar uma correção e relatar a alteração para a ramificação HEAD. Às vezes, porém, pode haver razões válidas para não corrigir uma versão anterior (como você mencionou), e liberar a versão mais recente que já corrigiu o problema pode ser a melhor solução. De qualquer forma, esta é a sua escolha, e a única maneira de poder corrigir uma versão anterior é tê-la no repositório e rotulá-la adequadamente.

Editar: sobre o assunto do SVN, como escreveu @ PéterTörök, a fusão de filiais é muito mais fácil do que com alguns outros repositórios de origem, você já fez uma boa escolha lá.

    
por 14.12.2011 / 11:55
fonte