Index: ch04.xml =================================================================== --- ch04.xml (revision 10) +++ ch04.xml (working copy) @@ -70,76 +70,78 @@ - Using Branches + Usando Ramos - At this point, you should understand how each commit creates - an entire new filesystem tree (called a revision) - in the repository. If not, go back and read about revisions in - . + Neste ponto, você deveria compreender como cada commit cria + uma nova árvore de sistemas de arquivos completa (chamada + de revisão) no repositório. Em caso negativo, retorne e + leia sobre revisões em . + - For this chapter, we'll go back to the same example from - Chapter 2. Remember that you and your collaborator, Sally, are - sharing a repository that contains two projects, - paint and calc. - Notice that in , however, each - project directory now contains subdirectories named - trunk and branches. - The reason for this will soon become clear. - + Para este capítulo, voltaremos ao mesmo exemplo do capítulo + 2. Recorde que você e seu colaborador, Sally, estão compartilhando + um repositorio que contém dois projetos, + paint e calc. + Note que na , por + outro lado, cada diretório do projeto agora contém subdiretórios + chamados trunk e branches. + A razão para isso logo se tornará clara. +
- Starting repository layout + Disposição do repositório inicial
- As before, assume that Sally and you both have working - copies of the calc project. Specifically, you - each have a working copy of /calc/trunk. - All the files for the project are in this subdirectory rather - than in /calc itself, because your team has - decided that /calc/trunk is where the - main line of development is going to take - place. + Como antes, assuma que Sally e você tenham cópias de trabalho + do projeto calc. Especificamente, cada um de vocês + tem uma cópia de trabalho de /calc/trunk. + Todos os arquivos para o projeto estão nesse subdiretório ao invés + de /calc em si, porque sua equipe decidiu que + /calc/trunk é onde ocorrerá a + linha principal de desenvolvimento. - Let's say that you've been given the task of performing a - radical reorganization of the project. It will take a long time - to write, and will affect all the files in the project. The - problem here is that you don't want to interfere with Sally, who - is in the process of fixing small bugs here and there. She's - depending on the fact that the latest version of the project (in - /calc/trunk) is always usable. If you - start committing your changes bit-by-bit, you'll surely break - things for Sally. + Digamos que lhe tenham dado a tarefa de fazer uma + reorganização radical do projeto. Isso leverá um tempo enorme + para ser escrito, e afetará todos os arquivos no projeto. O + problema aqui é que você não quer interferir Sally, que está + em processo de correção de pequenos defeitos aqui e lá. Ela + depende do fato de que a última versão do projeto (em + /calc/trunk) está sempre utilizável. + Se você começar a realizar commits das suas mudanças bit-a-bit, + você com certeza trará problemas para Sally. - One strategy is to crawl into a hole: you and Sally can stop - sharing information for a week or two. That is, start gutting - and reorganizing all the files in your working copy, but don't - commit or update until you're completely finished with the task. - There are a number of problems with this, though. First, it's - not very safe. Most people like to save their work to the - repository frequently, should something bad accidentally happen - to their working copy. Second, it's not very flexible. If you - do your work on different computers (perhaps you have a working - copy of /calc/trunk on two different - machines), you'll need to manually copy your changes back and - forth, or just do all the work on a single computer. By that - same token, it's difficult to share your changes-in-progress - with anyone else. A common software development best - practice is to allow your peers to review your work as you - go. If nobody sees your intermediate commits, you lose - potential feedback. Finally, when you're finished with all your - changes, you might find it very difficult to re-merge your final - work with the rest of the company's main body of code. Sally - (or others) may have made many other changes in the repository - that are difficult to incorporate into your working - copy—especially if you run svn update - after weeks of isolation. + Uma estratégia é rastejar para um buraco: você e Sally podem + parar de compartilhar informações por uma ou duas semanas. + Quer dizer, comece extraindo e reorganizando todos os arquivos + da sua cópia de trabalho, mas não realize commit ou update até + que você tenha acabado completamente a tarefa. Existe um número + de problemas com isso. Primeiro, não é muito seguro. A maioria + das pessoas gosta de salvar seu trabalho ao repositório + frequentemente, digamos que algo ruim aconteça a sua cópia de + trabalho. Segundo, não é muito flexível. Se você faz seu + trabalho em diferentes computadores (talvez você tenha uma cópia + de trabalho de /calc/trunk em duas máquinas + diferentes), você necessitará copiar manualmente suas mudanças + de um lugar para outro, ou fazer todo o trabalho em somente + um computador. Similarmente, é difícil compartilhar suas + mudanças em progresso com qualquer pessoa. + Uma boa prática comum do desenvolvimento de + software é permitir que os outros revisem seu trabalho tão logo + o faça. Se ninguém vir seus commits intermediários, você perde + um potential retorno. Finalmente, quando você concluir todas + as alterações, você talvez ache difícil mesclar seu trabalho + final com o restante da linha principal de código da sua empresa. + Sally (ou outros) pode ter feito muitas outras alterações no + repositório que sejam difíceis de incorporar a sua cópia de + trabalho—especialmente se você executar o comando + svn update após semanas de isolamento. - The better solution is to create your own branch, or line of - development, in the repository. This allows you to save your - half-broken work frequently without interfering with others, yet - you can still selectively share information with your - collaborators. You'll see exactly how this works later - on. + A melhor solução é criar seu próprio ramo, ou linha de + desenvolvimento, no repositório. Isso permite a você salvar seu + trabalho não concluído frequentemente sem interferir com os + outros, já que você pode ainda compartilhar seletivamente + informações com seus colaboradores. Você verá exatamente como + isso funciona mais adiante.