Mail Archives: geda-user/2014/10/17/02:45:31
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
- Raw text -