X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
Date: Tue, 8 Dec 2015 13:19:11 -0500
Message-Id: <201512081819.tB8IJBrt022764@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: geda-user AT delorie DOT com
In-reply-to: <B2F4DA99-3254-4C97-A408-854445A09C21@noqsi.com> (message from
	John Doty on Tue, 8 Dec 2015 07:26:29 -1000)
Subject: Re: [geda-user] gsch2pcb after refdes-renum? (If implemented syncronization detail)
References: <56658683 DOT 401 AT envinsci DOT co DOT uk> <CALT8Ef4=tMf=WmjYmp-2B3rN0SBmoqF5RkCoWZEm=+2hTBTENA AT mail DOT gmail DOT com> <20151207153821 DOT c2ac19e6f24b1776a3595e4a AT gmail DOT com> <CD4C755E-8E00-427D-909C-3F762A038844 AT gmail DOT com> <20151208091411 DOT c8968b0bedb705765529176c AT gmail DOT com> <B2F4DA99-3254-4C97-A408-854445A09C21 AT noqsi DOT com>
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> We've discussed this many times, and the problem is the unrestricted
> semantics of symbol instance copying.

Is there any research being done on this type of tracking?  Given the
large number of changes that can happen to a schematic between
exports, it seems like you'd have to store the entire history in each
component.  "The NAND gate U5 that was at X,Y in heirarchy A/B/C last
Wednesday is now NOR gate U4 at X2,Y2 in heirarchy E/F/G".  Even a
simple rename is dangerous if you accidentally run it twice.  It seems
to me to be even more complex than merging patches in a big source
tree.

Yet, despite the complexity, it sounds like something users want to be
able to do...