On Thu, Sep 9, 2010 at 8:38 PM, Tech Geek <techgeek12...@gmail.com> wrote:
So the concepts of trunks, branches, tags are transparent to SVN. We are in a 
situation where we might need to have two trunks in one SVN repository. The 
reason is that we have a family of projects - say ProjectA, ProjectB, ProjectC 
and so on, each one has it's own repository and have just one trunk (normal 
setup) since the each of these project has just one part.
 
But now let's say we have a ProjectD which has two sub-systems - PartA and 
PartB whose code is 95% different. So we are thinking to have two trunks inside 
the ProjectD repository. We would prefer not to create an individual repository 
for PartA and PartB because we have decided to categorize each of the 
repository based on the family of Projects - ProjectA, ProjectB, ProjectC, 
ProjectD.
 
Just wanted to know to get some thoughts from the experts on this mailing list 
regarding this setup. Any gotachs I need to watch out for?
 
Thanks!
===
Maybe I missed something in your scenario,
but I would simply have one trunk with PartA and PartB as sub-directories.
===
That would depend mostly on your branch and merge patterns. I have a similar 
situation. Since every branch has both projects in it, every workspace that I 
use to do merges has to check out both projects, even though no merge ever 
contains changes to both projects. Quite a pain in the rear. To make it worse, 
the unix developers use filenames that cannot be created on a windows system 
(e.g. AUX, COM1, and COM4), so we can't do merges on windows systems at all. 

At my top level I have code, vendors and tools. 'code' contains all of our 
code, the other two are for imports.

So instead of /code/trunk/proj1 and /code/trunk/proj2, I should have 
/code/proj1/trunk and /code/proj2/trunk. Then I could branch and merge each 
project separately. But before I do this, I should make absolutelty sure that 
these two projects have no interdependencies.

AFAIK, branches are just names. So above and beyond fixing up your mergeinfo's 
(if you have any), this should work just fine.

JLM


Reply via email to