At my company, we have your typical svn structure. Each project has branches, tags and trunk.
repo -Project A * trunk * branches * tags -Project B * trunk * branches * tags -Project C * trunk * branches * tags -Project D * trunk * branches * tags -Application 1 * trunk * branches * tags
So Project A is core functionality pretty much all of our other projects use. D may depend on C & B as well, and application 1 uses them all. Note that we have many more libraries and applications than I've illistrated above, but its all done the same way. The assemblies generated by building project A are included in needed library or application projects as externals. We've got quite a few libraries like this.
What we've been doing after a release is tagging the RC branches we created for each project used by the application, and then these then become tags.
Obviously this is a fair amount of work as we ensure that tags only point to other tags, and you start by creating the tag for Project A, making the other stuff point to that, etc., the idea being we want to branch from the tags should a patch release be required before our next feature release.
Given the amount of effort that can be involved getting this all together, one proposal is to tag only the application's RC and for all the externals point to a specific revision. If we need to create a branch to fix one of the libraries, branch from that revision and do the work then.
I'm not against this, as I would like to not have to spend the time getting all the tags for all the projects setup, but I wanted to ask, can anyone think of any pitfalls of this approach? Is there any reason to create these tags over just pinning to a specific revision?