Mail Archives: geda-user/2014/10/17/09:32:13
gedau AT igor2 DOT repo DOT hu writes:
> On Fri, 17 Oct 2014, John Griessen wrote:
>
>> On 10/16/2014 12:43 PM, Enoch wrote:
>>> 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.
>>
>>
>> We have attributes. All that is needed for a VCS merge to work easily is
>> same handling of white space in file structure no matter how or in what order
>> a drawing is created. Possibly another external tool could alphabetize
>> the lines in a .sch or .pcb file so each collaborator would have
>> merges go in the same spot in the files... or possibly that "alphabetic
>> sorting" of lines of a .sch or .pcb file could be done internally.
>>
>> I don't see any need or anyone with time to spend on reinventing a VCS within
>> PCB or gschem, just use one externally on the data.
>>
>
> In general I agree: reinventing VCS in each tool is a bad thing.
>
> In some details I do not agree, and probably all these stem from the same source: meaningless diffs. IIRC there have been some efforts to make the tools keep some order (of objects, attributes, etc)
> on save/edit/load cycles, which reduced the amount of diffs by reducing the noise.
>
> However, looking at a diff on two sch files or two pcb files won't really show the user what's changed except for a few very trivial cases:
> - when a specific existing numeric/text data field has changes (e.g. drill size in pcb, attribute data in sch)
> - when a few existing elements are deleted and nothing else changed
> - when a few new elements are added and nothing else changed
>
> Where it certainly won't help:
> - object coord changes, things getting moved around in pcb
> - logical connections change in sch
> - pcb element or sch symbol gets replaced
> - sch element gets embedded or unembedded
>
> In my practice after the initial few commits the latter group makes up majority of the changes. In my experience the PCB file format is more friendly to diffing (in the sense that reading the diff on
> a terminal may yield useful result) while the sch format is nearly unusable this way. Please note that I do know the formats a bit, I often write scripts processing/editing both pcb and sch files -
> still, I find the sch format generally hard to manually handle both in original form and in diff form.
>
> Some of the above issues could be solved by changing the file format, especially on sch where coordinates of things shouldn't matter much; for example a format that would:
> - store symbols+attributes blocks separately from coordinates
> - would be restructured and indented for easier manual read (my daily PITA is figuring which attribute blocks are corresponding to which component and which attribute survives of the multiple blocks
> of an embedded sym)
> - a new structure should actively help diff to show useful context; if there are like 10 attributes of a symbol and the value of the last one changes, in the diff the attribute value change is
> visible, but usually not enough context to identify which component's attribute has changed; increasing the number of context lines doesn't help since this would increase the nosie too
> - separate coordinate info and pin connection info on nets; e.g. instead of a list of coordinates, a net would be a list of connection between named component/pins and where needed (automatically
> named) non-component hub points
>
> Diff on such a format would reveal how the connections have changed (among with a set of random-looking coord changes at the bottom which the user then could simply ignore).
>
> However, I can't imagine anything similar for PCB - PCB is all about the geometry of the layout, so all about coords and I don't think any textual diff would be fully readable on these. This means
> meaningful diffs in PCB world would mean a GUI diff tool unfortunately. I know about a graphical PCB diff tool, but that operates with diffing rendered PNGs (IIRC); that's not really comparable to
> diff(1).
>
> Once one accepts the above for PCB, it's a valid question whether the same should be done to gschem instead of changing the file format to be more diff(1) friendly.
>
>
>
> However, once the diff problem is solved, with file format change, with external tools or with new features within the tools, I wouldn't go any further in VCS integration, especially wouldn't try to
> integrate with a specific VCS system (or a group of specific VCS systems). As a UNIX user I believe a VCS should be used as a VCS and an (pcb, schematics, etc.) editor should be used as an editor. So
> far I prefer gschem and pcb over more integrated suites exactly for this sort of decoupling.
>
> Regards,
>
> Tibor
I have a dream that one day we shall all have a git-blame like gschem
display mode, I have a dream :-)
Thanks, Enoch.
- Raw text -