Itamar O, yes you are almost there, I have to say very intelligent guess. I
am indeed talking about FPGA development. The only difference is we have a 2
part FPGA on our embedded board. PartA and PartB are both FPGA codes which
are developed separately for their respective chips and then later they are
concatenated into one single file which is then programmed by the vendor
tool on our boards.
Concatenation is also not a problem since that is done externally. The only
major issue is how do we store (keep in mind SVN principles of trunk,
branches, tags) the concatenated file (yes we need to store binary objects
too) in my proposed repostiroy structure?
I would like this to be as simple as it can be because the developers/users
of this system are not very SVN savvy.
Thanks!
On Thu, Sep 9, 2010 at 1:43 PM, Itamar O <itamarost_at_gmail.com> wrote:
> 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 23:07:20 CEST