tags:

views:

10

answers:

1

I'm new to SVN and am trying to find a workflow / SVN structure for my team that is as painless as possible.

Currently we have a SVN repo set up for internal use where we store code for development projects. This seems to be working well, but it gets tricky when projects require external libraries to work that are also under version control.

Currently I'm running a bash script to recursively delete .svn files from these external libraries in order to add them to our repo, but I'm sure this isn't the best practice. It would be nice to have the option of updating dependencies (some sort of repo to repo checkout perhaps).

Any suggestions on how I can improve this process?

(BTW.. the SVN client we are using is Versions. We'd like to avoid command-line-based solutions if at all possible.)

+1  A: 

The feature you are looking for is called "externals". This will let you "attach" a path from external SVN repository to yours at a particular location. You can set it up so that updates to a working copy of your project will also get the latest code from the external project, or you can force the external project to stay at a particular revision, if you want more control.

Most clients I have used support this feature, though I can't speak for Versions.

As an alternative, rather than checking the external project out with SVN, have you considered downloading the source tarball of a particular release of the project?

Nick Meyer
That's exactly what I was looking for, thank you. Excuse my ignorance, but what advantage is there to a source tarball over checking out a project from a repo?
findzen
@findzen If you want to ensure you have an exact version as released by the project (like 1.8.0, for example) and don't see yourself updating very frequently, that may just be easier then setting up an svn:external property. Whatever suits your taste, really.
Nick Meyer