On Thu, Sep 9, 2010 at 8:38 PM, Tech Geek <techgeek12345_at_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
Received on 2010-09-09 20:23:02 CEST