Configurar a propriedade svn:externals para uma pasta no teu projecto. Esta propriedade consiste em uma ou mais linhas; cada linha tem o nome de uma subpasta que quererás usar como pasta de checkout para código comum, e o URL do repositório do qual queres efectuar aqui checkout. Para mais detalhes consultar “Itens Externos”.

Submeter a nova pasta. Agora quando actualizares, o Subversion trará uma cópia desse projecto do seu repositório para a tua cópia de trabalho. As subpastas, se necessário, serão automaticamente criadas. De cada vez que actualizares a tua principal cópia de trabalho, irás também receber a última versão de todos os projectos externos.

Se o projecto externo está no mesmo repositório, qualquer alteração que lá fizeres, será incluida na lista de submissões, quando submeteres o teu projecto principal.

If the external project is in a different repository, any changes you make to the external project will be shown or indicated when you commit the main project, but you have to commit those external changes separately.

Dos três métodos descritos, este é o único que não requer instalação no lado do cliente. Assim que os externos sejam especificados nas propriedades da pasta, todos os clientes irão adquirir pastas povoadas, assim que actualizarem.

Cria uma nova pasta no teu projecto para conter o código comum, mas não o adiciones ao Subversion.

Selecciona TortoiseSVN → Checkout para a nova pasta e efectua o checkout da cópia do código comum lá para dentro. Agora tu tens uma cópia de trabalho separada, aninhada na tua cópia de trabalho principal.

As duas cópias de trabalho são independentes. Quando tu submetes alterações na cópia pai as alterações na CT aninhada são ignoradas. por sua vez quando tu actualizas o pai a CT aninhada não será actualizada.

If you use the same common core code in several projects, and you do not want to keep multiple working copies of it for every project that uses it, you can just check it out to a separate location which is related to all the other projects which use it. For example:

C:\Projects\Proj1
C:\Projects\Proj2
C:\Projects\Proj3
C:\Projects\Common
        

and refer to the common code using a relative path, e.g. ..\..\Common\DSPcore.

If your projects are scattered in unrelated locations you can use a variant of this, which is to put the common code in one location and use drive letter substitution to map that location to something you can hard code in your projects, e.g. Checkout the common code to D:\Documents\Framework or C:\Documents and Settings\{login}\My Documents\framework then use

SUBST X: "D:\Documents\framework"
        

to create the drive mapping used in your source code. Your code can then use absolute locations.

#include "X:\superio\superio.h"
        

Este método só irá funcionar num ambiente apenas-PCs, e precisarás de documentar os mapeamentos de unidade de rede, para que a tua equipa saiba onde estão esses ficheiros misteriosos. Este método é para uso estrito em ambientes de desenvolvimento fechado e não é recomendado para uso geral.

The maybe easiest way is to simply add the project in a subfolder to your own project working copy. However this has the disadvantage that you have to update and upgrade this external project manually.

To help with the upgrade, TortoiseSVN provides a command in the explorer right-drag context menu. Simply right-drag the folder where you unzipped the new version of the external library to the folder in your working copy, and then select Context Menu → SVN Vendorbranch here. This will then copy the new files over to the target folder while automatically adding new files and removing files that aren't in the new version anymore.