Batch 'svn cp' on the server-side

Question

I have a monolithic trunk which is comprised of many projects and their corresponding shared modules. I wish the database was organized in a more flexible manner, but it isn't. What I'd like to do is create a branch which is a sort of project-specific refined view of the trunk. Really, it's a tag, because I only want to write it once however I only want to label select parts of the database. What's the way I can do this while generating the least amount of commit noise?

From the command-line in my working space, I could svn cp the working space directories to the branch folder (selecting only the modules particular to a project). However, the trunk is quite a large checkout and there are potentially very large number of items to move. So, this quickly becomes cumbersome.

Using svn cp on the server url allows me to selectively copy each path to the branch/tag folder as I see fit, but I get a commit per copy operation. When our projects are stable enough, the commit log messages are usually useful for project managers, so this level of commit noise would be annoying.

What I'd like to do is either copy the trunk with a set of filters. Or, alternatively, copy the trunk wholly then delete the unneeded folders (generating only two commit messages). But, as far as I can tell, there's no way to 'batch up' deletes or copies on the server side. Is this correct? Any other alternatives?

Answer 1

I'd check out the trunk into a working directory, probably using the --depth option so that I don't have a big source tree (see http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.checkout.html). The biggest benefit of this approach is that you can play around, throw away any mistakes, and do a single commit.

Answer 2

The svn manual covers a section called Externals Definitions.

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 loca- tions in a repository or perhaps from different repositories altogether.

Maybe svn:externals is a slik solution around the limited repository design you have to deal with.