This is something that proposes to solve the hardware and wireware in one system: http://www.makeblock.cc/. They're pretty new -- their kickstarter campaign just finished.
I just got an Arduino for Christmas, and I'm having a blast learning electronics. (I'm programmer by profession, so the coding part is only mildly challenging/interesting.)
The thing I've been enjoying about the Arduino is the community. When I hook an LED up, why do I need a resister? How do I compute -which- value resister I need? What do I need to run a 1A brush motor? So far I've very often found these questions have already been answered (with ideas, suggestions, hardware, etc).
I keep the inportant bits of my system in a CVS repository. It's not the most elegant, as it requires some work to "stitch" the checked out directory into all the places programs look for configuration info.
Plusses: tolerant of transient network trouble; can keep per-machine mods (just don't check them in); one universal distributed set of vim tweaks, yeah!
Minuses: each ~/.config file symlinked into the directory (ugg); per-machine mods requires a bit of a CVS dance sometimes; most probably unix-only
A big caveat with this is that I've only used it with two systems, both running the same version of the same distro. So, umm..., there are most likely complications abound.
"Biodiesel can be operated in any diesel engine with little or no modification to the engine or the fuel system." http://www.biodiesel.org/resources/faqs/
You didn't mention how many active developers are working on your project.
Where I work, we ran into trouble with CVS when we had 40+ active developers working in the same repository. If you have many different teams whose changes overlap on (even a few) common files, it can be difficult. In theory, branching helps with this, but in practice, branching just moved the conflict-resolution to a different step of the release process.
Hmmm... I guess a lot of our trouble was from how we organized our source tree and assigned projects. (Blame the managers!:)
For a while we had switched over to BitKeeper. It has it's limits, and we where definitely pushing them:) but it's a well thought out product. It did help manage the risks associated with code conflicts.
Slashdot Mirror
and I said nothing...
AvE (crusty canadian enginerd on youtube) had a couple of interesting videos on this:
https://www.youtube.com/watch?...
https://www.youtube.com/watch?...
This is something that proposes to solve the hardware and wireware in one system: http://www.makeblock.cc/. They're pretty new -- their kickstarter campaign just finished.
I just got an Arduino for Christmas, and I'm having a blast learning electronics. (I'm programmer by profession, so the coding part is only mildly challenging/interesting.)
The thing I've been enjoying about the Arduino is the community. When I hook an LED up, why do I need a resister? How do I compute -which- value resister I need? What do I need to run a 1A brush motor? So far I've very often found these questions have already been answered (with ideas, suggestions, hardware, etc).
Hey, I drive 70mph and change lanes frequently, and get 43mpg :) (2001 Prius)
And I like perl.
I keep the inportant bits of my system in a CVS repository. It's not the most elegant, as it requires some work to "stitch" the checked out directory into all the places programs look for configuration info.
Plusses: tolerant of transient network trouble; can keep per-machine mods (just don't check them in); one universal distributed set of vim tweaks, yeah!
Minuses: each ~/.config file symlinked into the directory (ugg); per-machine mods requires a bit of a CVS dance sometimes; most probably unix-only
A big caveat with this is that I've only used it with two systems, both running the same version of the same distro. So, umm..., there are most likely complications abound.
Well... the biodiesel part, yeah...
/
:)
"Biodiesel can be operated in any diesel engine with little or no modification to the engine or the fuel system."
http://www.biodiesel.org/resources/faqs
A hybrid kit is another matter
I've never used SourceSafe.
:)
:) but it's a well thought out product. It did help manage the risks associated with code conflicts.
You didn't mention how many active developers are working on your project.
Where I work, we ran into trouble with CVS when we had 40+ active developers working in the same repository. If you have many different teams whose changes overlap on (even a few) common files, it can be difficult. In theory, branching helps with this, but in practice, branching just moved the conflict-resolution to a different step of the release process.
Hmmm... I guess a lot of our trouble was from how we organized our source tree and assigned projects. (Blame the managers!
For a while we had switched over to BitKeeper. It has it's limits, and we where definitely pushing them