Project files management (was Re: Welcome)

[Werner Almesberger]

Lothar Behrens wrote:
>> One advantage of using a text-based format for EDA-specific files
>> would be that SVN and friends wouldn't choke on them :-)
> 
> At least netlists and BOM's could be used to figure out differences.
> If source code is available, even patching netlists would be a way -  
> with an additional step of placing
> new components on the sheet manually.

I was just thinking of what sort of mess it would leave in the
SCM. If the files are text, the effect of most changes would be
relatively small and wouldn't put an undue burden on the SCM.

> It was about sorting the nets and the parts and pint out which parts  
> then are on different nets. It saved the project :-)

Heh :-) Such a script to compare two netlists for equivalence
would indeed be useful. E.g., when someone sends a patch you
can't or don't want to apply automatically, you could still
verify that, in the end, all the manual changes yield the same
result.

That would be similar to "diff without the whitespace changes."

But also a way to compare two files for identity and to highlight
the changes would be useful.

> Using an half look through layer for two versions would be a way :-)
> Also helpful would be a visual 'offset' to ease spotting of small  
> differences.

Hmm, four layers perhaps ? Layer "before", layer "after", layer
"removed" (present in "before" but no identical copy exists in
"after"), and one layer "added". If one could toggle layers from
color to grey/invisible, that should be sufficient for visually
finding all the changes. If items in each layer can be deleted,
it would even be possible to check off the changes one by one.
Add an "items in this layer" count to know when you're done.

> KICAD supports subsheets, so these may be 'modules'.

And they go into separate files already. Cool, problem solved :-)

> Using a virtual PCB ontop of another PCB may also be a module.
> (System on a module, but board would be the same at the end)

That would new code, right ? In general, I find that KiCad lacks
the ability to merge "boards" into larger structures, e.g., to
make panels. By introducing an object that is a - possibly
recursive - "live" reference, we could have something that serves
both purposes.

Properly separating the netlists would be a little harder, but
then, if one runs the DRC only at the level where everything
should come together, that's probably good enough to get started.
(You'd see other people's mistakes, but that's not so different
from compiling programs ;-)

Getting new items from the netlist would be messy if we don't
have a means to separate netlists. But perhaps solving that can
be deferred until a "phase two", and one would either add new
things manually or get the whole rabble, pick the one one really
wants, and delete the rest. Some sort of external tool could also
help.

> The KICAD sch and brd files are at least plain text. But it will be  
> hard to 'understand' the differences if you are
> not a 'crack' or a KICAD programmer. (I am not that crack :-)

Yeah, I think some visual helps are indispensable for normal
work. But it's good to have an easy access to the internals if
necessary.

> The Lines do not seem having an ID that also is used in 'connections'  
> from line to pin.

That would again be needed for a test for equivalence. A visual
comprison could do without it.

> It would be better, if the EDA tool stores the 'project' in a  
> database. Then a team could work on the same a little better.

Hmm, I'm somewhat sceptical about the concept of "joint editing".
I think distributed editing with tools that help to merge the
result would go a long way. You can do the "locking" on IRC :-)

Instead of a patch, you would just send the resulting file in one
way or another. That's the fallback mode for code as well, if
someone sends you something cryptic that doesn't seem to fit
anywhere. Bandwidth is cheap :-)

So ... seems that all that's needed to make KiCad better for
collaborative development would be:

- a "diff" mode for eeschema and pcbnew that shows the content of
  two files in four views ("a", "b", "a-b", and "b-a"), with ERC,
  netlists, etc., only being done on either the current view or
  just "b".

- a new object for pcbnew that acts as a "live link" for other
  .brd files and just merges whatever is in them into the current
  board, with the appropriate offset.

Still looks feasible ;-)

- Werner