On Thu, Sep 9, 2010 at 11:23 PM, Tech Geek <techgeek12345_at_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.
Received on 2010-09-09 22:44:22 CEST