delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2013/01/15/11:57:58

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Authority-Analysis: v=2.0 cv=T70Ovo2Q c=1 sm=0 a=6jktZp3dcHAl1vye2O6wCg==:17 a=jl9P3j1e7_0A:10 a=yqpquHFD9rMA:10 a=YW_e6Fk0WhoA:10 a=6WB07kdHjWAA:10 a=8nJEP1OIZ-IA:10 a=wR-FlJDvAAAA:8 a=py4ykTj1jEUA:10 a=crtLl8QKLy9t3l9ekz4A:9 a=wPNLvfGTeEIA:10 a=6jktZp3dcHAl1vye2O6wCg==:117
X-Cloudmark-Score: 0
X-Authenticated-User:
X-Originating-IP: 70.113.67.117
Message-ID: <50F58A89.1040004@ecosensory.com>
Date: Tue, 15 Jan 2013 10:57:45 -0600
From: John Griessen <john AT ecosensory DOT com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] geda-skeleton-project: Lowering the cost of a starting
a gEDA project
References: <87wqvhd4tw DOT fsf AT gmail DOT com> <kd21ao$j6j$1 AT ger DOT gmane DOT org> <20130115013756 DOT 9917 DOT qmail AT stuge DOT se> <CAOP4iL0yLZ-gvovCy5zCmJyjOXUUaoOB5U1+6CqcD20BM15FiQ AT mail DOT gmail DOT com> <50F4E4D1 DOT 3010802 AT ecosensory DOT com> <CAOP4iL1f=3TV5UKUjyJtpUw_5oBDxpk=5S2F=dEcUC2UYiNhVQ AT mail DOT gmail DOT com> <878v7uv4gl DOT fsf AT gmail DOT com>
In-Reply-To: <878v7uv4gl.fsf@gmail.com>
Reply-To: geda-user AT delorie DOT com

On 01/15/2013 09:41 AM, Ben Gamari wrote:
> In the case of git, one can handle the case
> of multiple source repositories with git-submodule. Other modern VCSes
> have similar facilities. There are much better tools than cp(1) for
> dealing with archival and versioning.


So, you like having it all in one repository?  Fab files are just a lot of chaff
when you go to do another design with some reuse.  I think John Eaton is
thinking of the good possibilities of so many people now developing
open hardware -- that sharing becomes a big thing, and yet, when you
think of fab files it can be a ton of clutter, and your fab is not their fab,
and your style is not their style and that's OK.  The snapshot need is for forensics
mostly, not usually looked at for a new design, so I can see it being in a separate
repository with clear tags related to product lines so it can be purged as
products die.  You still have the design sources repository project entries
that have a much longer lifespan since they are reusable, and in the open hardware cases,
shared, published and so deserving a little tidy up.  I can see separate repositories.
Even if that means using cp and doubling the data stored sometimes.

I tried using git submodule to separate datasheets from other design data and decided
the way submodule was used and syntax and reviewing notes on using it was too complex
for me to be enthusiastic about.

What is a good place to keep datasheets handy for redesign/reuse, and is there any optimum
compression method for them?  Are there tools that will disassemble pdfs, apply
best compression, and reassemble them so they are equivalent?  Some are compressed more than others.
Should we just leave them as their creators published them to be a legal document specification?
They're almost always public.

Is setting up a web server on a LAN or on the internet with links to them the way to handle
their largeness?

For now, I leave them out of a RCS and keep them in one directory
relative to all my projects.  That's not a group friendly way...

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019