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 <stambau...@verizon.net>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@lists.launchpad.net > >> Unsubscribe : https://launchpad.net/~kicad-developers > >> More help : https://help.launchpad.net/ListHelp > > > > > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : kicad-developers@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp