Re: Version Control for VHDL Project

On May 17, 2:24 pm, "KJ" <kkjenni...@xxxxxxxxxxxxx> wrote:
"Charles Gardiner" <inva...@xxxxxxxxxxxxxxx> wrote in message

news:gupq5e$m3p$01$1@xxxxxxxxxxxxxxxxxxxx



KJ schrieb:

What method do you use to lock down the revision of the subversion
external
references within the customer repository (for archival purposes) but
still
allow the latest/greatest revision to be used for development (or future
customer enhancements)?  svncopy.pl?  Manually?  Something else?

KJ

I followed the subversion suggestions here. Each reusable unit (and of
course each customer project) has a tags, branches and trunk
subdirectory. Every project release to a customer is tagged (svn copy)
and the output of 'svn -R propget svn:externals .' documented just for
safety.

Creating tags using 'svn copy' though doesn't lock down the revision of
externals when creating the tag so when you go back later to get the tag and
check it out, anything from an 'svn_external' will return the 'head'
revision of the referenced folder, not the revision that existed at the time
that you created the tag...good thing you have the 'svn -R propget
svn:externals .' documented so you know which revision was really used at
the time the tag was created.

Kevin,

I've been using Subversion for FPGA designs for quite awhile now and
I've come up with what I think is a reasonable workflow.

Of course lots of things are reusable, and anything that is so is a
separate project in the repository. As an overview, my repository
structure is as follows:

---------------------------------------------------------------
root\fpga\projects <-- All chip-level designs go here
\projects\A\tags\
\branches\
\trunk\src\ <-- VHDL goes here
\projects\A\trunk\fitter\ <- synthesis/P+R stuff
\projects\A\trunk\testbench\ <- obvious!
\fpga\models <- various simulation models for
testbenches
\fpga\modules <- resuable "cores" go here
\fpga\modules\spimaster\tags\
\branches\
\trunk\src
\trunk\testbench
\pwm\tags\
\branches\
\trunk\src\
\trunk\testbench\

----------------------------------------------------
Now here is how it works. When I'm doing a new FPGA design that needs
an existing module, I always use TAGGED versions of those modules.
This means I put the svn:externals property on the design's src
directory as follows:

spi svn://repo/fpga/modules/spi/tags/spi_v1.0.0/src
pwm svn://repo/fpga/modules/spi/tags/spi_v1.1.0/src

(don't forget the src, otherwise you get the testbench for the module
too!)

Now when you check out the FPGA design, you get the tagged (by
convention, immutable) versions of those modules.

If you are developing a new module along with your FPGA design, still
keep it as a module, but just include the trunk of that module until
you decide that it's ready for "release," at which point you tag it.
Oftentimes I will check out the submodule into its own working copy,
code it up, verify with the testbench, and commit, and only after
that's done will I add it to the externals for the larger design.

If you decide to change a tagged module, change the external to
reference either the trunk of that module, or create a branch of it.
Update the FPGA design's working copy and now you are developing on
the module's trunk. When you are finished and satisfied that the
module works as required, create a new tag, then change the chip
design's src directory's externals to reference the module's new tag.

Basically, then, when you decide to release the whole design, ALL of
the submodules pulled in by svn:externals should be TAGGED versions,
not from their respective trunks. So when you check out your design's
released tagged version you get what you expect, regardless of later
changes to any modules, which I suppose is the whole point of version
control.

I like to add the .bit and .mcs files to my design release tags, too.
Here's what I do. Before you tag your FPGA design for release, check
out a working copy (all tagged submodules!) _from the trunk_ and build
it. When complete, do an svn add on the .bit and .mcs files. (You
might wish to create a separate directory for these files under the
project root, and add that directory instead.) Do NOT commit the
change. Instead, create a tag from the _working copy_ (very easy in
TortoiseSVN). When that's done, your repo has a tagged release version
of the FPGA including .bit and .mcs. The working copy remains on the
Now, do an svn revert on the .bit and .mcs files because there's no
reason the trunk should contain build results.

Anyways, it's actually easier to use than to describe, and it works
for me.

-a
.

Relevant Pages

  • Re: branch / trunk in SVN
    ... A way to mark a static copy of set of files. ... it's a branch from the main 'Trunk' dir (where ... you should tag it as a release ... before you do the fix, and tag it again after you've done the fix, ...
    (comp.lang.ruby)
  • Re: Version Control for VHDL Project
    ... externals when creating the tag so when you go back later to get the tag ... anything from an 'svn_external' will return the 'head' ... The externals property takes an optional revision number: ... exactly recreate all source files as they really were at the time of ...
    (comp.lang.vhdl)
  • Re: How to use SVN + PHP
    ... Live-server works as client of the rep, getting the latest tag ... Develop-server uses mainly latest trunk and of course branches as needed ... we just emulate it by copying a folder to another folder. ... Better is to commit early, commit often and thus get "deep undo" through ...
    (php.general)
  • Re: [OT] - Svn Multiple Repositories on Windows
    ... Administration) of the Subversion manual should give you some good pointers. ... I installed SVN Server on Windows a few weeks ago using SVN-1- ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Version Control for VHDL Project
    ... Creating a tag does not ... repository of a particular project (i.e. the top level of the design) ... statement if there are either no externals or every external is explicitly ... What happens is the integrator is burdened with having to ...
    (comp.lang.vhdl)