I currently have 2 locations of code: codeA and codeB.
CodeB is a copy of codeA, but multiple developers have access to codeB. There will be regular updates to codeA that will need to be integrated into codeB.
I am trying to think of how this fits into svn's constructs (using trunk and branches/ the copy-modify-merge methodology).
Should codeA and codeB be separate repos? In this case, I would merge codeA into codeB, but I don't see a "trunk" or "branch" in this approach.
Should codeB maybe be considered my trunk? In this case codeA would be considered a "branch" and then I could merge any updates to codeA into codeB?
I usually use trunk as the one folder that I update most often, and branches I use for some separate temporary or permanent works. Temporary works are usually merged into the trunk once or a few times, and permanent works are merged from and into the trunk many times (preferably from the trunk in most cases).
You are free to abandon terms "trunk" and "branches" and use folders "codeA" and "codeB". They are just folders in the repo, and there isn't anything magical about folders named trunk and branches.
But if you can organize your projects and your code such that all the code exists in only one place that would be perfect. This should be your goal, if you can achieve it. The best way to merge is not to do it at all.