Question

I’m currently having the following setup in my SVN-repository:

-Root
--ProjectA
----trunk
----tags
----branches
--ProjectB
----trunk
----tags
----branches
--ProjectPool
----projectA
----projectB

Where ProjectPool contains specific tags of ProjectA and ProjectB.

Now the tags in ProjectPool change from time to time. This means a specific trunk-version of ProjectA is commited and I want to create a copy from this revision into Root/ProjectPool/projectA. The new tag should replace the old tag, but there should be a history available.

Its like having a branch on my computer which I never change and from time to time merging the trunk into it. But it should be done on the repository completely. (without having to checkin/checkout etc)

This would allow me to look into Root/ProjectPool/projectA’s history and see the changes of it. Kind of a high-level revision-history.

UPDATE:
I’m sorry I forgot to ask a clear question -.-
After viewing the answers which have been arrived until now, I would say that the copies of projects in ProjectPool are branches of the original projects. I then could merge them from trunk anytime I need a new version in ProjectPool.
The question now is, if there is a way to do the merging “online”, without having to create a working copy first.

Answer 1

>>Now the tags in ProjectPool change from time to time.

Tags are milestones, they should not be changing. You should create a new tag on each release.

>>This means a specific trunk-version of ProjectA is commited and I want to create a copy from this revision into Root/ProjectPool/projectA. The new tag should replace the old tag, but there should be a history available.

What you need here is a branch of ProjectA under ProjectPool which you can repetitively merge with trunk of ProjectA. With something like this

  svn merge sourceURL1[@N] sourceURL2[@M] [WCPATH]

refer: http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.merge.html

>>This would allow me to look into Root/ProjectPool/projectA’s history and see the changes of it. Kind of a high-level revision-history.

Looks like you have gone ahead with your directory structure. I would suggest you to follow this structure, if possible.

-Root
    +--ProjectPool
        +--ProjectA
            +----trunk
            +----tags 
            +----branches
        +--ProjectB
            +----trunk
            +----tags
            +----branches

You can release ProjectA and ProjectB in their tags. Newer development will continue in trunk. For any side development, or spot release, create a branch in branches directory. When branch is done, merge it back to trunk. This way your trunk will always reflect all the revisions and changes. And, this is more handy (and conventional).

Hope this helps.