Bureaucrats, cc_docs_admin, cc_staff
2,879
edits
(copy original from CQ) |
(replace internal stubs with external links) |
||
Line 12: | Line 12: | ||
== Families of Revision Control Tools == | == Families of Revision Control Tools == | ||
The principal revision control tools can be divided into two ''families'' or ''generations''. First generation tools, which include [ | The principal revision control tools can be divided into two ''families'' or ''generations''. First generation tools, which include [https://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] and [https://en.wikipedia.org/wiki/Apache_Subversion SVN], use a single central repository. All of the modifications are under the control of and retrieved from this authoritative repository. Second generation tools such as [https://en.wikipedia.org/wiki/Git_%28software%29 Git], [https://en.wikipedia.org/wiki/Mercurial Mercurial] and [https://en.wikipedia.org/wiki/GNU_Bazaar Bazaar], use local repositories. The advantage of such a system is that development work can be done independent of any remote server. The ''commit'' and ''checkout'' operations can thus be much faster and perform more complex operations. As an example, Git and Mercurial offer advanced management of branched development. In a branched development model, each new feature corresponds to a branch of the development tree. The ''production'' version of the project then corresponds to the principal branch and additional features are developed in parallel until they are sufficiently mature to be fused with the principal branch or else abandoned and the branch left to die. This development model is particularly well-adapted to very large projects involving several programmers. | ||
In exchange for this flexibility, with second generation tools all modifications that need to | In exchange for this flexibility, with second generation tools all modifications that need to go to an external repository must do so in two steps: first, they are submitted to the local repository (''commit''), then they are pushed (''push'') to the external repository. Equally so, to retrieve the modifications from an external repository, you must first obtain them (''pull'' or ''get'') so they can be imported into the local repository, then update your working version (''update'' or ''checkout''). | ||
== Choosing a Tool == | == Choosing a Tool == | ||
If you want to contribute to an existing project, you don't really have any choice - you will have to use the tool that has been chosen by the initial development team. If you are starting your own project, the choice will depend on the breadth of your project. If it's a project with only a few contributors, which will remain private and for which you would simply like to have a history of all the modifications, first generation | If you want to contribute to an existing project, you don't really have any choice - you will have to use the tool that has been chosen by the initial development team. If you are starting your own project, the choice will depend on the breadth of your project. If it's a project with only a few contributors, which will remain private and for which you would simply like to have a history of all the modifications, a first generation tool like [https://en.wikipedia.org/wiki/Apache_Subversion SVN] can be sufficient. If your project is larger, with external collaborators, you should consider a second generation tool like [https://en.wikipedia.org/wiki/Git_%28software%29 Git] or [https://en.wikipedia.org/wiki/Mercurial Mercurial]. | ||
<small>This page is derived from [https://wiki.calculquebec.ca/w/Gestion_de_code_source].</small> | <small>This page is derived from [https://wiki.calculquebec.ca/w/Gestion_de_code_source].</small> |