kicad-developers team mailing list archive

[Clemens Koller <cko@xxxxxxxxx>]

Hi, Wayne!

On 2016-01-12 15:42, Wayne Stambaugh wrote:
> You can do all of this already.  However, it requires some effort on
> your part.  This is what I do for my companies released designs so the
> next guy has everything necessary to recreate the board with no
> additional configuration of KiCad.

Yes, a versioned, well documented and portable design is
quite essential to conform to some standards customers expect
you to follow. Creating diff's of designs (schematics as well
as layout) is not trivial, but extremely useful.
However, cloning directory trees and zipping them away into
name+version+date.zip is not really a modern approach to
address that.

> We could create a tool that does this for you automatically but
> I'm not sure how useful that would be.

It would avoid the Kicad users to re-invent the wheel again
and again, each on their own.

> Many organizations have specific methods for documenting their projects
> that would be difficult to accommodate with this type of feature so I'm
> not sure how useful it would be.

There is no real industry-standard, AFAICT.
Ok, there is ODB++ and IPC2581, etc.... nice. But I haven't seen
a proper version control even in very pricy tools. Usually,
all the data is locked into a proprietary "vault", which is not
really an option if you need to work across different toolchains.

Currently, I export designs into ascii formats and use git, which
seems for me most efficient way.
Maybe I can share some ideas with that once I got more designs
into Kicad.

(Here, it would be great if the export functions of my commercial
tool would deliver consistent ordered/sorted output files,
but it doesn't. I bet that's just another try to lock
customers to their proprietary stuff.)

Regards,

Clemens


> On 1/11/2016 8:36 PM, Clemens Koller wrote:
>> Hello, Cirilo!
>>
>> I am quite new to Kicad-dev, but here is my novice idea:
>>
>> I would expect to have a 3D model embedded/frozen in my
>> "design database" at the time when I add it to my design.
>>
>> The design must not change when the model changes outside
>> of the "design database" without my knowledge/interference.
>>
>> Files outside of my design will change by definition.
>> I.e. some 3D models on the network get an update/rename
>> from the MCAD department while I am on holiday.
>>
>> I can update my design in my database when I decide to do
>> so by 'update 3D model from file' and commit/save it
>> locally when I am satisfied with the new model.
>> Therefore, a 'show me changed 3D models' diff is needed
>> as well (checking the SHA1-Sum (or timestamp at the least)).
>>
>> The "design database" can be simply a subdirectory in
>> the working directory where the 3D model copies reside.
>> I.e. by naming them with their SHA1-Sum.
>> (In the long term a real database might be useful for
>> performance reasons.)
>>
>> That basic idea applies not only for 3D models... also
>> for components taken out of libraries and put into the
>> library-cache.
>>
>> Just my five cents.
>>
>> Regards,
>>
>> Clemens
>>
>> On 2016-01-12 02:05, Cirilo Bernardo wrote:
>>> Hi folks,
>>>
>>>  I'm looking for some comments/suggestions on how to deal with 3D model
>>> filename resolution. My current 3D refactor branch behaves in much the
>>> same way as the main branch except that I can specify many model
>>> search paths. Issues with this scheme include:
>>>
>>> 1. how do we deal with multiple equivalent filenames
>>>
>>> 2. when the file's full path is not a superset of an existing search path
>>> how do we ensure that the stored path is a valid path on MSWin/Linux/
>>> OSX? 
>>>
>>> For (1) I'm thinking we can use a scheme similar to fp-lib-table where we
>>> specify a 'nickname' for a base path and provide for an optional comment/
>>> description. The chief issue I see with this scheme is that the kicad_pcb
>>> file will have to contain the nickname within the model name and earlier
>>> versions of kicad will not be able to process project files which have the
>>> nickname in the model name. This may not be such a big problem as the
>>> user can do a string replacement to transform the names, but if data is
>>> being shared both ways between 2 different kicad versions then the model
>>> naming can be a nuisance.
>>>
>>> For (2) I was thinking of converting the path to a path relative to the project
>>> directory. So "/home/user/models/a3dmodel.wrl" or "c:\models\a3dmodel.wrl"
>>> might become something like "../models/a3dmodel.wrl". The relative path
>>> will not necessarily exist on another computer but at least we don't have
>>> the complication of a MSWin vs UNIX file path root.
>>>
>>> Any comments/suggestions?
>>>
>>> - Cirilo
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>