Organizing my own external libraries in revision control

I want to set up a SVN repository to "revision-control" my projects. Currently my workspace looks like this, and I intend to keep it like that:

\workspace
   \myPrj1
   \myPrj2
   \myLibBase 
   \myLibA
   \myLibB

myPrj1 is using myLibBase and myLibA. myPrj2 is using myLibBase and myLibB. I will have more Projects coming up, that will use the libraries. I've written and am writing the libraries myself. While I am working on any of the projects I constantly tried to improve not just the project but also the libraries: find bugs, add features, etc.

Now how do I organ开发者_运维问答ize this in a repository?

This is my idea, but is it the best solution?

1. I will always use the workspace as the project root.
2. I will always include the libraries a project is using in the snv project folder
3. I will always have additional snv projects for the libraries

Then in the repository the above example would look like this:

\repository    
   \myPrj1 
       \myPrj1
       \myLibBase
       \myLibA
    \myProj2
       \myProj2
       \myLibBase
       \myLibB
    \myLibBase
       \myLibBase
    \myLibA
       \myLibA
    \myLibB
       \myLibB

Having it like this

...concerning the projects:

Whenever I check-in a working-copy of a project, I always have all sources, including the libraries check-in together. So when I check-out a revision, I always get all sources (including the libraries) as they were at the moment of the check-in.

...concerning the libraries:

Additionally I can check-in a working-copy of a library in the libraries svn project, when I think it is a nice and stable version. That version could then be checked-out when I create a new project.

Can somebody confirm that this is a good idea? Best practise? Is there a better approach? Can I find documentation/tutorials/.. on this topic? On the web? In a book?

Seems this is what you're looking for: Externals

Excerpt: "Sometimes it is useful to construct a working copy that is made out of a number of different checkouts. For example, you may want different subdirectories to come from different locations in a repository or perhaps from different repositories altogether. You could certainly set up such a scenario by hand—using svn checkout to create the sort of nested working copy structure you are trying to achieve. But if this layout is important for everyone who uses your repository, every other user will need to perform the same checkout operations that you did."

It basically works the way you want. It's OK, and necessary, to have multiple copies of dependencies when you need them to be at different revisions for whatever reason.

It doesn't seem to make sense having more then one copy of your library (let's say myLibBase) in the repository - version control is there to help you edit a single copy of your code, while keeping track of all changes. In the way you suggest (if I understand it correctly), you will have a versioned copy of myLibBase for each project, meaning that if you made a change to the library in your project, you end up with one of the 2:

1. You have different versions of the library, with the same name
2. You have to go and edit all versioned copies to be identical.

Either of the possibilities doesn't make sense to me.

Why wouldn't you have just one versioned copy of each library, and when you check-out a project, you'll have to also check-out the libraries this project need? That is, if you want to avoid checking-out other projects - otherwise you could just check-out the whole workspace.