← Back to team overview

kicad-developers team mailing list archive

Re: Duplicate schematic sheet names.

 

While we're on the subject of file formats, PLEASE, stop updating time
stamps in the header/comment when NOTHING else has changed. I can show you
commits to hw repositories with 30 eroneous files commited and only two
containing actual changes. The developer could have reviewed the changes
before committing, BUT, I'd argue that hardware devs are doing well to be
using version control at all, and I'd also argue that the level of
discipline required to not do such commits is above and beyond the call of
duty. This really amounts to a quite subtle (if you're not using version
control on your hardware designs) bad behaviour on KiCAD's part. Is there
any chance of rectifying it? To do it properly from a hw designers point of
view amounts to diffing all changed files, adding those with real changes to
the cache (if git), checking out the ones that have no real changes in them,
then committing. To go back and find the best place to fork a hardware
design where this has been done on every commit is an utter nightmare. It
also implies that saving the project does not keep track of which files have
been edited and which have not. That seems a little dirty, don't you guys
think? I'd be up for taking a crack at fixing it, but someone with intimate
knowledge of the KiCAD source would likely do it in 1/10 the time. Thoughts?
Time to promote good practice in version control for the hardware designers
on your team? :-)

On Wed, Aug 31, 2011 at 9:02 PM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx>wrote:

> On 8/31/2011 9:36 AM, hauptmech wrote:
> > On Wed, 2011-08-31 at 08:29 -0400, Wayne Stambaugh wrote:
> >> On 8/31/2011 2:12 AM, jean-pierre charras wrote:
> >>> Le 30/08/2011 21:44, Wayne Stambaugh a écrit :
> >>>> I was looking over open bug reports a while back and ran across this
> report:
> >>>> https://bugs.launchpad.net/kicad/+bug/593782.  While technically not
> a bug, I
> >>>> can understand why a user would be confused by this.  Should we
> prevent
> >>>> duplicate sheet names?  In the future it may be a problem as I am
> trying to
> >>>> avoid using the current time stamp solution to hierarchical schematic
> designs
> >>>> in the new schematic file format for readability reasons.  Anyone else
> have any
> >>>> thoughts on this?
> >>>>
> >>>> Wayne
> >>>>
> >>>
> >>> I believe we should not accept duplicate sheet names.
> >>> Yes this is confusing, and duplicate sheet names are a potential source
> of bugs.
> >>>
> >>
> >> JP,
> >>
> >> Thanks for the reply.  I already have a patch to prevent the user from
> entering
> >> duplicate sheet names on a schematic page.  However, it doesn't address
> the
> >> case where schematics already have duplicate sheet names.  I'll commit
> the
> >> changes that I have and take a look at what can be done for existing
> schematics.
> >>
> >> Wayne
> >
> > One possibility is to add a 'description' field (which is what many
> > users would have been using the 'name' field for if they used
> > duplicates), copy the name into the description and then unique the name
> > any way you like.
>
> In the forthcoming file format I would like to avoid the way we currently
> handle complex hierarchies using a path of time stamps.  Unless you
> understand
> how the time stamp paths work, this:
>
> AR Path="/4B3A1333/4B616B96" Ref="R25"  Part="1"
>
> is not human readable.  This is the reason that duplicate sheet names is
> not an
> issue with the current design.  I'm thinking of using an inheritance design
> similar to how the SWEET file format remap component pins for assigning
> reference designators and part numbers for components with multiple parts
> per
> package in sheets.  I can add a description to the sheet definition in the
> new
> schematic file format specification.  I do not want to open up the new
> schematic file format discussion again until I finish the initial draft.  I
> should have this done by the end of September.  You can follow the original
> discussion by search the mailing list archives for new schematic file
> format.
> After I publish the specification, we can reopen the discussion to finalize
> the
> spec.
>
> Wayne
>
> >
> >>
> >> _______________________________________________
> >> 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
>

Follow ups

References