Sometimes you will want to include another project within your working copy, perhaps some library code. There are at least 4 ways of dealing with this.
Stel de svn:externals
eigenschap in op een map in je project. Deze eigenschap kan één of meer regels hebben; elke regel bevat de naam van een sub-map welke je wilt gebruiken als de doelmap voor gemeenschappelijke broncode en de URL van het archief waar vandaan je de gegevens op wilt halen. Lees voor meer details de paragraaf met de naam “Externe Objecten”.
Leg de nieuwe map vast in het archief. Zodra je nu ververst, zal Subversion een kopie van dat project maken vanuit het archief naar jouw werkkopie. Sub-mappen worden automatisch aangemaakt als dat nodig is. Elke keer dat je je werkkopie ververst, wordt ook de laatste wijzigingen van het externe project opgehaald.
Als het externe project zich in hetzelfde archief bevindt, dan worden de wijzigingen die je daarin aanbrengt meegenomen in de vastleglijst als je het hoofdproject vastlegt.
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.
Van de drie beschreven methodes, is dit de enige methode die geen instellingen vereist aan de kant van de gebruikers. Als de externen eenmaal toegekend zijn aan de map-eigenschappen, zullen alle gebruikers automatisch de betreffende externe gegevens krijgt als zij hun werkkopie verversen.
Create a new folder within your project to contain the common code, but do not add it to Subversion.
Selecteer
→ voor de nieuwe map en haal een kopie van de gemeenschappelijke broncode op. Je hebt nu een aparte werkkopie genest in jouw hoofd werkkopie.De twee werkkopieën zijn onafhankelijk. Als je wijzigingen vastlegt van de bovenliggende map, dan worden wijzigingen in de geneste werkkopie genegeerd. Ook als je de bovenliggende map ververst, wordt de geneste werkkopie niet ververst.
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"
Deze methode zal alleen een PC-omgeving en je moet nauwkeurig aangeven welke schijfletters er toegewezen moeten worden, zodat je team weer waar ze de mysterieuze bestanden kunnen vinden. Deze methode moet je alleen gebruiken in een gesloten ontwikkelomgeving en is niet aanbevolen voor generiek gebruik.
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
→ . 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.