Mail Archives: geda-user/2014/10/16/18:30:42
On Thu, Oct 16, 2014 at 1:54 PM, Ivan Stankovic <pokemon AT fly DOT srk DOT fer DOT hr> wrote:
> On Thu, Oct 16, 2014 at 01:43:25PM -0400, Enoch wrote:
>> What I am more interested in drawing the attention to is their
>> presumably easy collaboration at schmeatics ("data") level. Geda does an
>> impressive colaboration at tools, git and friends make it easy for
>> us. Generations of talented programmers keep this project alive for
>> years... but what about collaborative creation of data, the next
>> BeagleBone like design?
>
> I'm afraid more and more designs of such complexity will probably not be
> made by using gEDA, except maybe for few people that have their own
> private forks, scripts and basically very special workflows that,
> really, should not have been necessary.
>
> Although I do not want to beat a dead horse (again), I have to say that
> gEDA simply does not address the issues of modern complex designs.
> Complex designs require much better integration and more functionality
> than is currently provided by gEDA.
Exactly what are you thinking of, besides the ability to *encapsulate*
what you have done, and *share* it?
> Now, I'm sure there are some who will jump in and say that every design
> that can be done using other EDA tools can also be done using gEDA. And
> while I may agree for the most part, I have to ask, at what cost?
> Sure, you could conceivably build a house with only a hammer and a
> shovel, but would you really want to?
>
>> Suppose you and I work on a common design project, you move resistors
>> around, you change values, ... how am I supposed to see your changes, by
>> doing a diff on the sch or pcb ASCII files... I believe that Geda should start
>> adding tags to the sch and pcb which are related to version control.
>>
>> In short, add revision control support within gschem, within pcb, etc.
>>
>> Is this a pipe dream?
>
> I'd say it is.
So how many crazy people really do hardware design this way? If you're working
on the same subsystem as me, and you come in and make changes like the above
without talking to me, I'm gonna be pissed. scm is a terrible substitute
for communication even for software and doubly so for hardware, where the
coupling of all the pieces of a subsystem is usually pretty tight. Forget
about collaboration tools designed to compensate for designer deficiencies
and worry about more fundamental capabilities, like sharable modules.
Britton
- Raw text -