Mail Archives: geda-user/2014/10/17/09:32:59
I agree that we want to use external version control. Besides people
will want to use the one they are most friendly with. Forcing everyone
into one integrated into the tool will start a "My VCS is better than
yours" fight that I want no part of.
When I said visual diff I meant taking the schematics exported as PDF
and a diff on those images not a diff on the text. There is code for
this.
On Fri, Oct 17, 2014 at 1:45 AM, <gedau AT igor2 DOT repo DOT hu> wrote:
>
>
> 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
>
>
--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
- Raw text -