You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Dan Notestein <da...@syncad.com> on 2005/06/20 22:01:26 UTC
Benchmarking for SVN?
Maybe this already exists, but if not, I wanted to suggest that the
Subversion project adds a benchmark report on a test svn respository of
a set size and hardware configuration. This would be a nice way to
measure the performance of svn as it goes through changes, and it would
also give users a way to recognize if their performance was below
average due to a bad configuration of some kind. The benchmark could
include the speeds for the most common commands and set up to run
automatically on new releases.
Re: Benchmarking for SVN?
Posted by Brandon Ehle <az...@yahoo.com>.
I had a benchmarking framework a while I used to compare SVN vs P4 vs CVS.
http://subversion.kicks-ass.org/perfnew/elapsed.html
The hard part about making a benchmark that runs over an extended period
of time is that the results aren't very useful if the machine you are
running doesn't get locked down. Things like the kernel, filesystem
free disk space, etc all affect performance and may skew the results
beyond usefullness.
Maybe a slightly better approach would be to do something in the line of
a CMake like build status page that has these benchmarks built in.
While not very useful by themselves, you can detect problems if suddenly
one platform gets much slower than the others by looking at the averages.
http://www.cmake.org/Testing/Dashboard/20050621-0100-Nightly/Dashboard.html
Dan Notestein wrote:
> Maybe this already exists, but if not, I wanted to suggest that the
> Subversion project adds a benchmark report on a test svn respository
> of a set size and hardware configuration. This would be a nice way to
> measure the performance of svn as it goes through changes, and it
> would also give users a way to recognize if their performance was
> below average due to a bad configuration of some kind. The benchmark
> could include the speeds for the most common commands and set up to
> run automatically on new releases.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Using Subversion for both hardware and software versioning
Posted by kf...@collab.net.
Stephen, please see
http://subversion.tigris.org/mailing-list-guidelines.html#fresh-post
...about how to avoid accidentally joining unrelated threads.
Thanks,
-Karl
"Stephen Turner" <sg...@audioscience.com> writes:
> We are currently using CVS for our sw versioning.
>
> We'd also like to put our hardware projects (schematics, FPGA code etc)
> under version control. The schematic files are binary - one reason why CVS
> is nota good choice.
>
> So, we are thinking of putting everything under Subversion.
>
> Question - should everything (h/w and s/w) be in one repository - i.e have
> one global version?. Our development dir tree looks something like this:
>
> base
> --hw
> --project1
> --project2
> .....
> --projectN
> --sw
> --applications
> --project1
> --project2
> .....
> --projectN
> --drivers
> --project1
> --project2
> .....
> --projectN
> --firmware
> --project1
> --project2
> .....
> --projectN
>
> We were thinking that maybe we should have one repository for h/w and one
> for s/w, but would like to hear from other users who are using Subversion in
> a similar scope.
>
> thanks
> ------------------------
> Stephen Turner
> AudioScience, Inc.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Using Subversion for both hardware and software versioning
Posted by Andy Peters <de...@latke.net>.
Stephen Turner wrote:
> We are currently using CVS for our sw versioning.
>
> We'd also like to put our hardware projects (schematics, FPGA code etc)
> under version control. The schematic files are binary - one reason why CVS
> is nota good choice.
>
> So, we are thinking of putting everything under Subversion.
>
> Question - should everything (h/w and s/w) be in one repository - i.e have
> one global version?. Our development dir tree looks something like this:
>
> base
> --hw
> --project1
> --project2
> .....
> --projectN
> --sw
> --applications
> --project1
> --project2
> .....
> --projectN
> --drivers
> --project1
> --project2
> .....
> --projectN
> --firmware
> --project1
> --project2
> .....
> --projectN
>
> We were thinking that maybe we should have one repository for h/w and one
> for s/w, but would like to hear from other users who are using Subversion in
> a similar scope.
(Before I start: I consider a "Tag" to be a read-only snapshot of the
design. Tagged files are used by production to build things, or are
otherwise considered non-modifyable.)
I'm a hardware guy, but of course "hardware" these days includes FPGAs
(designed using HDLs) and microcontroller and DSP firmware. I've gone
back and forth on how to organize things. The original idea was to
organize by project, and within each project is a folder for schematic
and PCB design (including BOMs and Gerbers), a folder for each FPGA, a
folder for micro or DSP firmware. The idea being that you could check
out the top level and get the whole picture.
But then things got complex. An obvious example is where one FPGA
design may be used on more than one board. (Make it more complex --
same code, different pin-out or device!) Or, a PCB gets built and there
are updates/fixes or just different versions of firmware or FPGA loads.
It became clear that the repository really had to be organized by "type"
-- like you describe, there's a folder called "fpga," a folder called
"firmware," a folder called "PCB," a folder called "host app," a folder
called "driver," and so forth, and under each are the specific projects.
Under "fpga," each project has a "src" folder where I keep all of the
synthesizable sources, a "fitter" folder where I keep FPGA synthesis and
place-and-route tool project and constraint files, and a "testbench"
folder where I keep the non-synthesizable test bench code.
Under "fpga," in addition to each project, I have a folder called
"models," which contains behavioral (non-synthesizable) HDL models of
various things that I use in my test benches. There's also a folder
called "modules," which has synthesizable "cores" that are usable across
multiple designs. These models and modules are included as necessary
using externals properties. Ideally, you'd create and verify the
modules and models and tag the "known good ones," and use the tagged
versions in the design. This way, if/when you update a module or model,
you don't break designs that use the older versions. (This should all be
completely obvious to software guys who reuse code all the time.) You
don't want to start a debug session by checking out a tagged FPGA
release and have it pull a newer version of your SPI module -- one
that's not what you actually burned into the FPGA!
You'll have to come up with a higher-level schema (outside of version
control) that relates specific designs (firmware/PCB/FPGA) to products,
but you probably already have something like that in place.
You can use Subversion's externals property to make a "product" tree
under the respository root so you can check out a specific release of
"gizmo" and get all of the underlying stuff. For this to work, you'll
need to keep everything in the same repository.
Anything that gets built or released to a customer gets tagged. When
you fab a PCB, the schematic, PCB files and Gerbers get tagged. An FPGA
load given to production needs to be tagged. Usually, you don't keep
.bit/.jed/.pof/.mcs files during development, but since the FPGA tools
can and do vary their results even if the sources are unchanged, it's
important to include the files used to program the parts in your tags.
You get the idea.
Anyways, this is all the result of using Subversion for hardware designs
for the last couple of years. Now that Subversion lets you lock files,
you can check out binaries (like PCB files and the like), lock them, and
other users will know that they shouldn't change those files since they
can't be merged.
Now, if only the FPGA vendors would make their tools more source-code
control friendly, we'd be getting somewhere. As it is, they all seem to
default to dumping everything into one big directory and not being clear
as to which files are actually important and which are just temporaries!
-a
-------------------------------------------------------
Andy Peters
5511 E Rosewood St
Tucson, AZ 85711
520-907-2262
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Using Subversion for both hardware and software versioning
Posted by Stephen Turner <sg...@audioscience.com>.
We are currently using CVS for our sw versioning.
We'd also like to put our hardware projects (schematics, FPGA code etc)
under version control. The schematic files are binary - one reason why CVS
is nota good choice.
So, we are thinking of putting everything under Subversion.
Question - should everything (h/w and s/w) be in one repository - i.e have
one global version?. Our development dir tree looks something like this:
base
--hw
--project1
--project2
.....
--projectN
--sw
--applications
--project1
--project2
.....
--projectN
--drivers
--project1
--project2
.....
--projectN
--firmware
--project1
--project2
.....
--projectN
We were thinking that maybe we should have one repository for h/w and one
for s/w, but would like to hear from other users who are using Subversion in
a similar scope.
thanks
------------------------
Stephen Turner
AudioScience, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org