On Thu, Sep 9, 2010 at 11:23 PM, Tech Geek <techgeek12...@gmail.com> wrote:
> I am thinking something like this: > > ProjectD > ProjectD/PartA/trunk > ProjectD/PartA/tags > ProjectD/PartA/branches > ProjectD/PartB/trunk > ProjectD/PartB/tags > ProjectD/PartB/branches > > Beleive me or not in our scenario the code of Part A and Part B never gets > merged at any point. The only common part is that at the end of each release > of Part A and Part B their output file is concetenated into a one single > file which is then programmed on a hardware part by an external tool. > > So for a scenario like that I would like to keep it very simple. Any > feedback or comments regarding the above structure? > > Thanks! > That actually sounds extremely similar to the way I set up repositories for projects in my organization. Different projects are unrelated, so they reside in separate repositories, but every project (which is an embedded-device) has software development and FPGA development, so the layout within the project is exactly what you described: proj/Software/[trunk,branches,tags] proj/FPGA/[trunk,branches,tags] If you case is similar, I recommend using the layout you described, and considering the following points: * Add proj/Tools (or something like that) to manage the scripts that concatenate the final image etc. * If you also use SVN to store the resulting images (we do, although it is usually not recommended to keep binary outputs in source control), consider adding proj/Releases for those. * If you have code-reuse between projects (we have reusable software modules and IP cores) - look into svn:externals and decide how to manage it in your set up. I haven't completed handling this in my set up (still in the process of migrating from VSS..), but I plan to have a dedicated repository for "shared assets" and have specific projects define the assets they use based on absolute svn:externals.